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