Re: New package managment

[Pierre Phaneuf <pp@ludusdesign.com>]

Bryan Patrick Coleman wrote:

> > Dynamic linking has that nailed. That's why you'll see ".so" files with
> > version numbers after them.
> 
> I have seen that not work often enough to be extreamly skeptical that it
> could in all cases.

This is a common misuse of the soname in libraries. They are NOT
supposed to reflect a fixed version number! They are supposed to
increase by one only when binary compatibility is lost.

For example, glibc 2.0 and glibc and glibc 2.1 both have the same soname
(libc.so.6) because a binary built on a glibc 2.0 system will work
perfectly on a glibc 2.1 system without the need for compatibility
libraries. Some might argue that since binaries built on a glibc 2.1
system don't work on a 2.0 system that the sonames should be different,
but over all, it is better to give some work to developers (they have to
use the "compat" kit that come with the Red Hat and SuSE distribution,
for example, to compile the binary packages) than to make users install
two different versions of the libc.

> > I agree with Pierre - we don't need yet another binary package manager.
> > RPM's and their ilk have that covered.
> 
> I would not divorce it from rpm's just an enhancment. So you could still
> just pull down the rpm :)

There should only be RPM packages (or Debian packages). All that you
want to do could effectively done via an wrapper program over 'rpm', a
program using librpm or improving 'rpm' itself.

This is what you mean, right?

For example, this would be similar to 'autorpm', a Perl script that
checks the errata packages and upgrades packages automatically. I think
Gnorpm also check for library dependencies when you use it to install
packages.

I never used dpkg or apt-get, but as I understand it, the Debian system
has a single list of packages, which is the largest single advantage I
could see, since it gives you a good master list to get packages from.
Red Hat tried to have such a master list with their RHCN (Red Hat
Contrib Network), but it didn't go very far, as I see it.

The problem I had most often with RPM packages is bad packages, that
don't even work correctly on a stock system. That's not even counting
bugs in some packages (as the qt and qt-devel packages of RH6, the
libqt.so link is in the wrong package, leading to conflicts when
installing a newer qt library).

These problems are likely to happen also with Debian packages and no
package system can probably hope to "fix" them.

> > We don't need a new source manager either, autoconf/automake are really
> > great.
> 
> Again developers tend to stay on the bleading edge. autoconf/automake things
> barf at least half the time. What end user is going to chasing around new
> versions of the build tools. I think all developers should try building
> there packages on at least the newest stable release of say redhat or
> caldera. Debian to be safe since its still on the old kernel. We should not
> be forcing average joe to keep there systems more upto date than the
> distro's. Unless you just want developers playing your game.

I use an almost completely stock Red Hat 6.0 system to develop and build
the release versions of Quadra. I only needed a few libraries from Red
Hat 5.2 that weren't in the "compat" packages (libvga.so.1,
libvgagl.so.1 and libz.so.1) that Quadra needs.

> > Look - we are *just* getting to the point where RPM and
> > autoconf/automake are reasonably "standard" - most binaries come in RPM
> > form and most sources as autoconf/automake.
> 
> why not srpms?

When you need patches to make a source package build correctly into an
RPM package, SRPMs are nice, but when nothing is needed, one cool thing
is simply including the spec file at the top of the .tar.gz hiearchy.
Then, you can simply use "rpm --clean -tb somepackage-1.0.tar.gz" to
build yourself a binary package.

-- 
Pierre Phaneuf
http://ludusdesign.com/