Re: New package managment

[Ingo Ruhnke <grumbel@gmx.de>]

"Bryan Patrick Coleman" <linuxgames@excite.com> writes:

> What I have in mind is a kind of supper package class that can do more (more
> easily) than what is out there.

I cannot think of anything easier than apt-get, installing a software
package alonge with the needed libabries with a one liner:

$ apt-get install pingus

> 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.

Hm, don't like that idea, that would mean to download a *huge* file
instead of several smaller ones, which apt-get would do automatically.

> 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.

What would be the advantage of using apt directly? Apt would download
all required libaries automatically, no need to group them all. And
how would your package system work on a non debian distribution, if
it is based on dpkg/apt?
 
> I also am going to include source in the packages so that binaries can be
> built from the same package.

That would only mean that the packages would grow larger, if I want to
compile a package myself, I get the source, if not I get the binary,
but I hardly can imagine a situation were I want both.

> 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.

I think thats nothing necessary, if I want to compile something from
source, than bassically for two reasons, I want to hack the thing,
or second the binary is older and then the current source. If I want
to remove a library than I use dpkg/apt or for source libs, I normally
never remove them (since I need them again at some time) or I do a 'make
uninstall'. 
 
> 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. 

IMHO statically binaries can be usefull, for tarball binary distributions,
which doesn't check for installed libaries. Since a static binary is
the easiest thing to make it work, but for a package system they are
not usefull, since the package system should resolve the missing libraries.

> 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.

ClanLib is still in development, so its normal that it happens from
time to time that the downward compatibility breaks, then I have to
fix Pingus and all is right again. For other libs, if they come in
binary form, its no problem, the distribution will handle or I
can still have different versions installed, for source packages, I
have then to trees with the different version and than 'make install'
them as needed, not to hard. 

To make it short, I think there is still no need for a binary package
system, dpkg/apt does a fantastic job. Please, don't try to fix
something that is not broken. If you think there is something missing
in dpkg/apt than please explain that a bit further.

For source packages, its true that there is something missing, but
there is no need for a packagement system or something similar, the
autoweb idea simple (as it does not try to replace something, but
instead extened it) and great, it does only need somebody to implement
it and test it.

-- 
                                  http://dark.x.dtu.dk/~grumbel/pingus/ | 
Ingo Ruhnke <grumbel@gmx.de>             http://home.pages.de/~grumbel/ |
------------------------------------------------------------------------+