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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
