Magnus Holmgren <holmg...@debian.org> writes: > When a binary package is renamed or split, as well as if several packages are > merged under a new name, transitional packages are normally created, which > depend on the new packages, which in turn Replaces and Conflicts with, and > possibly Provides, the old packages. I find those dummy packages as silly to > create as to uninstall after upgrading.
Dpkg has the ability to vanish empty packages. A dummy package should be completly empty and not even contain a /usr/share/doc/. That way on installation the package pulls in its depends and then vanishes. So no more need to uninstall after upgrading. This only works if the superseeding packages Provide the old one though. Otherwise depends on the old package would become unsatisfied. Only problem is that this screws with the automatic/manual install flag. See below. > I propose a new control field called e.g. Supersedes that will provide the > same semantics. In its simplest form, a renamed package will declare that it > Supersedes the old package name. That will be considered equivalent to > conflicting with/replacing earlier versions of the superseded package, as > well > as providing a new version of it, just like a dummy package. Multiple > packages > can supersede the same package (but they should probably be the same > version), > and one package can of course supersede many others. > > This proposal should be feasible; APT scans all Packages lists searching for > the best version of a given package to install, doesn't it? so it will be > able > to find the Supersedes fields at the same time. > > This would, among other things, solve the git problem; gnuit would supersede > git, which would tell APT that the latter should be upgraded into the former, > and that git the VCS is something else entirely. > > -- > Magnus Holmgren holmg...@debian.org > Debian Developer Packages should tell when they superseed some other package. The conflicts/replaces/provides triplet was used for this in the past but no frontend ever looked for it. Also not every superseeding has used the triplet or should use it. I suggest that superseeding also includes a possible version as a package might only superseed an old version of something but not a newer one. Or a rename might be undone resulting in A superseeding B and B superseeding A. A version will tell the right order. Superseeding should also preserve the automatic/manual flag of the superseeded package. Currently if A was manually installed and becomes a dummy package then removing A will propose to remove the superseeding package too. WOrse if A vanishes as the superseeding packages would just silently appear in the removable list. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org