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 madco...@debian.org
OOO http://www.madism.org
signature.asc
Description: Digital signature
