packaging system

Mike Porter mupi at
Thu Oct 30 10:12:30 PST 2003

Hash: SHA1

On Thursday 30 October 2003 09:00 am, Emiel Kollof wrote:

> Use RedHat for a while (>6 months) on a workstation and find out why not
> yourself.
> > I'm not a big fan of RPM but the OpenPKG folks choose it for project
> > (which I happen to really like on Debian :-)
> >
> > The OpenPKG mentioned that they needed some sort of package management
> > system because it was unclear whether or not they could have written one
> > to be more successful then others out there.
> Well, successful does not imply quality. Look at Microsoft for a good
> example :)
rofl.  Actually though, in my experience, RPM is pretty good for distribution 
and upgrading of packages, but doesn't offer much in the way of reverting a 
version once upgraded. (Of course, the ports system suffers from that to some 
extent, too.)  RPM also lacks a central database of *available* packages, 
which is one of the things I like the most about the ports system (Granted it 
is a stretch to call it a 'database', but the point is, I can go to 
/usr/ports/games and look for things that interest me.)

> Portage can be quirky. And the package-support in portage leaves
> something to be desired. When I was using gentoo for a while, the thing
> I missed the most was BSD's tarball packages. Compiling glibc, moz, X or
> even KDE is NO FUN on a measly PII 400.
Heck, compiling X & KDE is no fun on a pIII 700, especially if it doesn't work 
the first time and you have to back up and try again. (voice of experience 
here, I embarked on what I thought would be an overnight upgrade that wound 
up taking about a week, during most of which time X was unusable due to some 
parts having a newer version than others....)

> I think we should mix and match. The upgradeability of Gentoo (which is
> one thing they got down right), and a robust packaging system. Also,
> when it comes to compiling apps, something like what OpenBSD does, which
> _always_ creates a package from a port, and then installs the resulting
> package.
I'm not sure why this is important.  If the port/package system is done right, 
there is no difference between a package and a port, except where it was 
compiled (and thus, possibly, optimizations).  As I see it, forcing a package 
build from a port seems to just add an additional 2 steps (tar && untar, in 
essence, which just adds time to the process, more time on a slower machine 
that a faster machine)

> Also, very important is being able to search in the package database. A
> facility to find out which package contains file foo, and of course
> "grepping" through the package db for apps that i.e. have CAD in their
> description or somesuch. Kinda like make search in the current ports
> tree, but without the hassle of having to regenerate/maintain an INDEX.

More than that, which package(s) contained (past tense) file foo.  In other 
words, which package installed a given file.  Although if we adopt something 
similar to the /package file tree, that can be obvious. 
/package/util/bar-3.2/foo obviously comes from the package 'bar-3.2'.

What I would like to see is an enhanced interface to a mechanism that probably 
is pretty close to the existing ports system in base functionality.  I would 
like to see an easier method for getting binary packages, and I think there 
can be some improvements to how things work in general (including, 
specifically, keeping the ability to access 'old' versions of 
ports/packages), better searching, and a better interface/search for 
installed packages.   Portupgrade is functionality that should be part of the 
base functionality of the system.  Finally, it needs to be ui-agnostic, so it 
can run from the console or from X.  Just for grins, when running from X, I 
would like the ability to run from non-root Users, by supplying the root 

my 2-or-so cents worth

Version: GnuPG v1.2.1 (FreeBSD)


More information about the Kernel mailing list