[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Transitional (dummy) packages considered silly

On Thu, Sep 17, 2009 at 11:52:23PM +0200, Magnus Holmgren wrote:
> 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.

Well, I'm not sure what the practical gain is, could you please
elaborate on the suggested Supersedes: semantics ?

Note that transitional packages are seamless for users. When users has
foo in $stable, and foo gets renamed into bar in $stable +1, then there
is that:

$stable: package foo
$stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts foo}
$stable + 2: foo is dropped, replaces/provides/conflicts foo in bar can be dropped.

After user has upgraded from $stable to $stable + 1, he doesn't have
'foo' anymore.

There is one point in having the transitional package: it ensures that
no package does try to take "foo" as a package name in $stable + 1 which
would then in turn confuse apt.

That is the state of the art. Could you please elaborate where and why
this field would help ?

FWIW I would be interested to read about a field semantics that would
solve the git issue properly.

IOW in lenny we have git being the GNU file manager stuff, and git-core
the VCS. If you find a scheme that would allow git-core to become git,
and git to become gnuit in _one_ release cycle[1] then your proposal is
worth it.
Finally, I think your proposal doesn't work, because "Supersedes" cannot
work if two distinct binary packages "Supersedes" the same binary. We
can obviously ensure this doesn't happen in the _same_ Debian
distribution. I don't see how we can feasibly ensure it across different
releases in a sane way (and I know lots of people having deb lines for
stable, testing and sid in their sources.list).

All in all, I think your proposal is just a shorthand to make your
debian/control marginally smaller and having to write extensive
(slow[2]) patches to dpkg, but also britney, dak and pretty much
everything dealing with .debs, for absolutely no real gain wrt the
current state of stuff.

[1] this is theorical discussion as such a proposal would need to be
    implemented in dpkg, then pushed to user, then used, IOW only
    squeeze+1 would be a target for "Supersedes" use anyway.

[2] yes slow, because for each package install, dpkg would have to
    wonder if anything supersedes it, and deal with all the issues that
    would arise if _two_ binary packages Supersedes the same thing.

·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: signature.asc
Description: Digital signature

Reply to: