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.
