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.
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 holmgren@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
Reply to: