Package management

[Stefan Urbanek]

Hi,

Package management is a dependencies hell. Why? There are millions of packages. 
There were several talks about package management for the GNUstep environment, 
however all of them were following known pakcage management techniques like 
.rpm or .deb. What is the problem with those? Very small granularity of 
packages. Is there a need for such granularity? Well, in most cases I think 
that the answer is no. So the proposal is: have large packages :-)

As noone picks which functions (and which algorithms) he wants in his libc, we 
can do similar at higher level with libraries, tools ,apps and frameworks. 
Bundle them in larger packages. Of course, keeping advanced users in mind. Even 
NeXT used large packages, so in GNUstep we can have, for example, packages 
like: Base, Environment, Development, DatabaseDevelopment, WebDevelopment, 
Communication, Office, Scripting, ...

Example packages:

Base
    gnustep-make
    gnustep-base
    libffi*
    libobjc*

Environment
    gnustep-gui
    gnustep-back
    libtiff*
    libjpeg*
    libfreetype*
    libart*

Development
    Gorm
    ProjectCenter
    CodeEditor

DatabaseDevelopment
    EOF frameworks

WebDevelopment
    GNUstepWeb

Communication
    GNUmail
    WebBrowser
    TalkSoup

... or something like that.

Each package should have two (or more) alternatives: native and guest. Native 
should bring all non-gnustep libraries with it (like libtiff, libffcall, 
libfreetype,... for package System). Libs for native packages  are marked *. 
They are missing in guest packages. Or no alternatives at all, just packages 
for specific platform (-debian-x86, -osx, -backbone-x86,...). User looking for 
an appropriate package should know: hosting environment/os and machine type.

Versioning is simple: when library versions inside changes, change version of a 
package. More libs changed-larger version change in the package (for example).

Of course, we can not avoid dependencies here neither. However, it is much 
easier to resolve dependencies on 1-2 packages than on a tree of 10-20 packages.

I think that this can bring easier package management. Users do not care about 
each particular library anyway, they care more about whole application suites 
or bundles.

What do you think? How do you see problems and advantages of this larger 
package granularity? And how can possible problems be solved?

Stefan
--
http://stefan.agentfarms.net

First they ignore you, then they laugh at you, then they fight you, then you 
win.
- Mahatma Gandhi