Re: New package managment

[Erik <br0ke@math.smsu.edu>]

On 25-Sep-99 Bryan Patrick Coleman wrote:
> On 25 Sep 1999 12:34:01 +0200, Ingo Ruhnke wrote:
> 
>> Pierre Phaneuf <pp@ludusdesign.com> writes:
>> 
>> > He did have a full setup of GNOME, KDE and plenty of candy installed,
>> > just no development tools, so I guess it isn't safe to assume "gcc" or
>> > even "make"!
>> 
>> You could be right.
>> Back to topic, we don't need a new package system for binaries, the
>> ones out there are good enough. So for a 'new' package/build system we
>> could safely ignore all those people out there without any development
>> tools and instead focus on the people out there which have a full
>> features linux installation (with gcc, etc.), but which build only a
>> very little number of packages themself (for example just the kernel).
>> 
> 
> What I have in mind is a kind of supper package class that can do more (more
> easily) than what is out there. I think I am going to use dpkg & apt as the
> underlying pakaging system. What I am envisioning is "grouping" several deb
> pakages into on superfile that can install or build packages as needed.
> 

you mean like debian meta packages? IE the task-gnome-* series? files with lots
of dependancies but no real content? or are you going to make one big huge
massive file with all of everything? I think the dependancy route is the way to
go, so if hermes fixes a bug, you don't need to download all of hermes,
clanlib, and pingus to get it fixed. :) (the task-gnome packages are extras
from the gnome for debian mirrors, www.gnome.org has more info. Other packages
are handled like this, too. Like when X went from being one big 'supper'
package to several smaller packages, to make incremental uprades easier and
faster)

> For example lets look at the Pingus situation. You have this supper package
> that contains clanlib and hermes libs for Pingus.
> 
> When you install the package it sees tha need to install the libs as well
> and does so.
> 
> I also am going to include source in the packages so that binaries can be
> built from the same package. Even using the option to build staticly linked
> binaries. Basicaly the libs would be installed for the build and then
> removed after the binary is built.
> 

most packaging systems have seperate source packages by concention, debian and
redhat both do it. If I just want the binary, i don't want the source. If I
want the source, I don't wanna wait around for the binary to d/l...

> I would like to say something in the defense of static linking. There is
> currently a glut in the lib market with new projects cropping up all the
> time. If each new game comes out and is using a different lib you really are
> not gaining anything. Plus what if you really want to games that use
> different versions of a lib that are incompatable. Say clanlib. Then you
> could have the new clanlib installed, but have the Pingus game do a static
> link with the old lib.
> 

static linking the non-standard (what a good ambigious concept :) libraries is
a good idea I think. Netscape and Code Forge both offer static and dynamic
linked binaries (as not everyone has motif libraries laying around). While you
can justify it by motif being commercial, it's still the same reason that would
drive static linking of games; not everyone has it installed. I beleive static
linking provides FASTER binaries, it eliminates of the overhead of code jumps
into libraries. The two big reasons for static linking are space and easy
upgradability (if everything's statically linked, you have to recompile
everything for every upgrade of anything important, like libc...)

> - Bryan Coleman (opium package development)
> 
> 
> 
> 
> ________________________________________________________________
> Get FREE voicemail, fax and email at http://voicemail.excite.com
> Talk online at http://voicechat.excite.com
> 

        -Erik <br0ke@math.smsu.edu> [http://math.smsu.edu/~br0ke]

The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep
Refrigerated.