[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Package management
From: |
Stefan Urbanek |
Subject: |
Package management |
Date: |
Mon, 01 Mar 2004 22:22:24 +0100 |
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
- Package management,
Stefan Urbanek <=