Colin Watson wrote: > Please go and understand why shared libraries need to include the soname > version in their package name, and then come back. If the version is > removed from the package name upgrades (certainly partial upgrades) > *will* break badly. And no, it's not particularly a hack: allowing > concurrent installation of multiple versions of a single package would > be much worse. .. > Well, if you feel like rewriting dpkg from the ground up (yes, your > ideas *will* require that) and making sure you can handle full > inter-release upgrades and partial upgrades correctly, feel free. Until > then we need to stick with what we've got, which is working pretty well.
It's not all _that_ hard. For example, consider a new field, IgnoreThisPartOfTheName. Package: gimp1.4 IgnoreThisPartOfTheName: 1.4 Here dpkg and apt need only be taught to remove the IgnoreThisPartOfTheName from the package name when displaying it, and to treat the result as a virtual package so users can query for it too. We wouldn't even need much of a transition plan for this, as older dpkgs could continue to use the packages. Or, a field called AddThisToThePackageName: Package: gimp AddThisToThePackageName: 1.4 Here dpkg can append the field internally to get its unique key. This would require a transition plan. These are not very good proposals, but they do show how gigantic changes to the whole package toolchain could be avoided. Of course, there is also this option: Package: gimp1.4 Provides: gimp And then make dpkg and apt treat virtual packages as more first-class packages, so you could instlal, remove and query a virtual package by name, and maybe modify frontends to do some smarter presentation using the provides fields than they do now. -- see shy jo
pgp00000.pgp
Description: PGP signature
