Re: Transitional (dummy) packages considered silly
Magnus Holmgren <holmgren@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.
>
> 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 holmgren@debian.org
> Debian Developer
What about a case where the superseded package remains in Debian. To
bring up an example from the past: You have both apache and
apache2. apache2 superseds apache but apache is still available and
apache2 is not just a rename but a new package providing a superior
implementation of the older package.
Could supersede be made to detect such a case? Frontends should
suggest updating to apache2 but not force this or do so automatically.
Maybe only supersedes + provides would go automatically and superseds
alone would onyl suggest the update.
MfG
Goswin
Reply to: