Re: dpkg 2.0?
I'd like to offer an opinion on the subject of dpkg and package
management in general. If this has already been mentioned elsewhere,
then so be it - I just didn't know where or when.
Now granted, this has nothing to do with the current state of dpkg 2.0,
which I'm sure will continue in its current direction regardless of what
I say here, simply because to do what I'm talking about would require
basically a total rewrite, and we certainly aren't ready for that.
I just want to mention a few things and see what everyone says. The
ideas have been on my mind for some time, and perhaps I'm way off, but
I'd think some of them are feasible.
What I would propose rather than just a package manager with download
and dependency checking, is that we look at other efforts such as
Conary, which as a lot of good concepts to offer, when designing the
next dpkg.
Some of the things that can really be a pain with the current system are
alternative packages, reconfiguring packages, personal repositories,
Epoch flagging, package rollback, and package scripting.
Now granted, some of these problems disappear, depending on your level
of experience with apt/dpkg/aptitude/dselect. My point is not that we
need to tell users to read the manual, but are there ways to make this
better so that we have less problems, and administrators will benefit.
Alternative package installations on Debian are normally just symlinked,
and while this is very handy, a lot of admins always look for an easy
way to manage the installed alternatives.
Reconfiguring packages, yes, it can be done, but it's often easier to
simply reinstall the package entirely to avoid personal hacks or
sometimes deleted files in /etc/init.d. IMHO, a reconfigure should be
total replacement, with the option of selectively allowing for overwrite
or backup of current files, rather than just trying to run install
scripts that sometimes don't work right after the original install.
Personal repositories are often desired but a pain to manage. I'd like
to see a local package flag that allows for the admin to selectively
override to leave locally created packages in place regardless of the
version number or Epoch flags that is assigned in the official packages.
Epoch version flags I've always found to be something of a kludge.
Granted, it works. But isn't there a better way of incorporating it
into the "control" package files? Maybe there already is and the
documentation just needs to be updated?
Package rollback to the previous version would be extremely useful,
especially where Sid is concerned, with dependencies often broken simply
by an overworked maintainer forgetting to change a version number in the
dependency chain in a package.
Package scripting in any distrib has always been traditionally a
double-edged sword, with the package being only as good as the
maintainer's scripts. One interesting solution that was put forth in
rPath Linux was rather than having package scripts individually written
from scratch, that the installs used a sort of "meta language" of
pre-built routines to install files - eliminating some of the errors in
scripts as well as providing a standardized base for future package efforts.
I also think we could go a bit further with alien packages, but let's
save that for another day, it's a separate issue, with lots of tough
questions.
Debian's package management is superior and faster than just about
everyone else, and yes, I have tried others. Apt/Dpkg runs circles
around Yum/Rpm, for example. I think we can one up it again.
T.J.
Reply to: