Re: Package management

[Dennis Leeuw]

I have thought about this too, that's why included the libsmbclient into 
the SMBKit package.

But I also want to deliver packages that are non-stripped... meaning the 
debugging symbols are still there. Afterall GNUstep is a development 
environment and debugging is part of that process.

This brings me to my actual point: the size of the packages. Not 
everybody has a highspeed, error free line.
That means if a bit is dropped on e.g. a 2 Mb package one has to 
re-fetch 2 Mb. If that happens on e.g. a 25 Mb package... you get the 
picture.

The benefit of small is the download speed. So I think we should package 
smartly. Include with a package the things it depends on, without 
duplicating work. That's the catch.

just my 2 cents

Dennis

Stefan Urbanek wrote:
> 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