Dpkg Update Proposal
Okay, I posted to -devel a few weeks back with a proposal for an update to dpkg.
This message is being Cc'd to -devel, and sent to -dpkg.
Basically, attached is my proposal (it's long, I'm trimming it down in another
rxvt, but, I wanted to get something out for the firing sqaud). Please read it,
and reply with questions, complaints, comments, suggestions, etc. Please don't
scorch me. If I want to be flamed, I'll post "RedHat sucks, Slackware is cool
and btw: KDE rocks" to Slashdot.
Any flames can be sent to /dev/null. Please just constructive stuff here.
I'd like someone with superior authority on dpkg, (Ian Jackson?) to also take
extra look at this.
In a nutshell, my proposal outlines the weirdness of package names
(libgtk1.1.13, svgalibg1, imlib, etc -- to name a few), and how to fix them, and
the possible problems it would cause.
Please, feel free to add to this.
Also, note that there is no code done as of _yet_, I want to take everything
into consideration first, but I have done a bit of research on dpkg to make sure
that this will work, and have considerable experience developing package
management systems (a lot of the SLP-0.90 code is derieved from my own), and I
have written up to and more than 80% of three different package managers, all
of which I discontinued after switching to _the_ real distribution.
-fantumn
================================================================================
Package Naming Scheme
-----------------------
The current naming scheme of many packages is a mess, to say the leasy. This,
of course applies almost exclusively applies to libraries, but there are some
other packages that could use some help (Electric Eyes, and Easy Editor come to
mind).
The problem is inconsistency. Some package names, speaking about libraries
here, are prefixed with the word 'lib', as in libgtk, and some are not, as in
Imlib. Now, I realize that this should be the case sometimes, as in libjpeg,
libtiff, etc (those are the proper names for those packages), and, libImlib
would sound funny. Some packages contain a little g, such as zlib1g, to show
that the package is compiled for Glibc2. However, not _all_ glibc2 packages
have this little g (imlib and fnlib come to mind). Since libc5 exists for the
most part only in the hearts of the Slackware users, this 'g' thing can be
dropped.
Another problem with this is that many packages comtain a number on the end,
so that different versions of the library can be installed (I assume), but that,
also is not consistent. For instance, freetype has two packages, freetype1 and
freetype2, where do the 1 and 2 come from? What significance do they have?
With a simple patch to dpkg (more details below), this could be fixed.
The other inconsistency problem, is that even though many packages have a
number, and the letter 'g', that is still not consistent. What order do they go
in? SVGALib has svgalibg1, and zlib uses zlib1g. Even more confusing is the
way gtk is named. libgtk1.1.12 is the latest, at time of writing. It was
always libgtk1, then libgtk1.1, then because the GTK developers break every
previous release with every new one, it had to start getting full version
numbers, as does the kernel package (kernel-image-2.0.36).
CVS
-----
CVS is becoming an increasingly important part of the daily life for many free
software projects (Gnome, Mozilla and Berlin come to mind), yet there is no
defined way to name a CVS package. Perhaps we can take the easy way out, and
not package programs from CVS, but what would us Enlightenment users do without
CVS versions? Enlightenment has not had a new version since 0.14 which was way
back this past summer, and it is severely feature-deprived (no iconization, for
instance). The current Enlightenment maintainer, Brian Almeida, has come up
with a wonderful solution for this. He calles all stable versions of
Enlightenment simply enlightenment, and CVS versions enlightenment-cvs. He has
fixed it further, by making enlightenment-cvs conflict with enlightenment.
Perhaps there are more examples.
Personally, I think Brian's solution to the CVS problem is the perfect fix,
but perhaps there is room in the Debian package format for a CVS version
numbering.
Fixing All of this...
-----------------------
Of course, to save being scorched, I have to include some solutions to the
problems outlined above. And, again to save being further scorched, I have to
provide _good_ solutions to these problems.
My solution, after long thought and working out, is to simply modify the
Debian Package Management system to allow multiple versions of packages to be
installed. (Keep reading, before anyone jumps to conclusions) This simple fix
would not severly break the current package management system, and would require
only that people upgrade to the new version of dpkg (which would be simple, if
we just include the patched up version in potato... everyone that upgrades to
potato gets the new dpkg). The numbers, and letters on the end of packages
could be eliminated, and a package naming standard should be imposed.
I envision a time and a place, where, when I read in a README something to the
effect of "This package requires GTK", I could just type "apt-get intall gtk",
instead of remembering that the name for the current gtk is "libgtk1.1.12". I
could also teach myself, that if I want the cvs version of GTK, it's package
name is gtk-cvs.
Of course, if I read "This package requires GTK version 1.1.6, no less, no
more" (unlikely, but it _could_ happen), I could just "apt-get install gtk
(1.1.6)". Perhaps even simple equations could be used. If the readme said
"This package requires GTK between 1.1.6 and 1.1.11", I could "apt-get install
gtk ( > 1.1.6 & < 1.1.11)".
Another feature that I would like to see implemented, is something that would
check all dependencies for dead libraries "ie, libraries that aren't used",
perhaps this would be done by a program seperate to dpkg.
Of course, I am willing to code this myself, or help code, I just want to pass
the idea around for evaluation. No code is done at the current time, but I have
done a bit of research to make sure that my ideas will work for the most part.
Compatibility
--------------
Again, I will touch on the compatibility issues. When the version of dpkg is
patched up to work like this, it will cause some headache, but not a whole lot.
Package maintainers would have to be warned to switch to the new naming scheme
(many wouldn't even have to switch), and users that refuse to upgrade dpkg, but
want the two latest versions of a program simultaneously, would be warned to
upgrade.
Also, if we introduced this new package manager update in the latest version
of Debian (perhaps the version _after_ potato), we would avoid all conflicts, by
telling maintainers of packages in the new version to use the latest naming
scheme.
Perhaps someone of high authority on dpkg could help me out with this. I am
convinced that this will work, and will need considerably un-convincing to send
me back to the drawing board.
Reply to: