packaging system
Mike Porter
mupi at mknet.org
Thu Oct 30 10:12:30 PST 2003
-----BEGIN PGP SIGNED MESSAGE-----
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.
>
agreed.
> > 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
password.
my 2-or-so cents worth
mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE/oVQIY30jZzkECLcRAqrkAKCqewoSG0x+WAK810g4v7ks9jXC/gCfTpIf
eNAgYtbHE0PAb3+tSr0ShbM=
=FNxg
-----END PGP SIGNATURE-----
More information about the Kernel
mailing list