On lördagen den 19 september 2009, Pierre Habouzit wrote:
> 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.
He still has the transitional package 'foo' until he decides to go looking for
transitional packages and removes it (after clearing the 'autoinstalled' flag
on 'bar'). If he doesn't do that before upgrading to $stable+2, there's a
chance that there is a different package 'foo' that 'foo' will be "upgraded"
to.
> 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.
A transitional package doesn't strictly prevent a maintainer from uploading
another source package with a binary package that takes the place of the
transitional package, as long as the version of the new package is greater,
which it has to be even if the old package only exists in stable, doesn't it?
> 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.
Let me elaborate on my last paragraph. The idea is that if 'bar' Supersedes
'foo', then versions of 'foo' greater than that of 'bar' (or an explicitly
declared version) are a different package and should not be considered for
upgrading 'foo'. For example:
lenny:
git 4.3.20-10
git-core 1:1.5.6.5-3+lenny2
squeeze:
gnuit 4.9.5-1
Supersedes: git (4.9.2-1)
git 1:1.6.4.3-2
Supersedes: git-core (1:1.6.4.3-2)
On upgrade, since gnuit supersedes git at version 4.9.2-1 (the first version
with the new name), it "cuts off" the path to git 1:1.6.4.3-2. So if you had
git you get gnuit, and if you had git-core you get git. Note that if you
explicitly ask for just git 1:1.6.4.3-2 when you have git 4.3.20-10, instead
of upgrading, you won't automatically get gnuit unless extra intelligence is
implemented.
> 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).
If two packages supersede the same package 'foo', then both should be
installed in place of 'foo' on upgrade, but only if they supersede the same
version of it (I suppose that's how it will have to be done). So you can have
e.g. (modulo syntactic details) foo 1.3.7-3, bar 1.3.7-4 (Supersedes: foo
(1.3.7-4), a new foo 1:1.0.2-1, then later a foo-bar 1:1.2.0-3 that Supersedes
foo (1:1.2.0-3), and it will be possible to deduce that foo 1.3.7-3 should be
upgraded to bar 1.3.7-4 and not to foo-bar.
Multiple different packages reusing the same name in subsequent releases seems
pretty contrived to me, however.
> 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.
I will concede that Supersedes should not imply Replaces or Conflicts, but
merely be a hint to APT. Then neither dpkg nor britney nor dak should need to
be patched. Though a question remains: Should dak reject a package that tries
to supersede a package of which a newer version already exists in the archive?
I don't think so; the other 'foo' could be uploaded before the superseding
'bar'.
Front ends for APT will have to be updated to present the new package
relationship though, like with Breaks, and to use it if they implement their
own dependency solving algorithms.
> [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.
Naturally.
> [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.
What about packages conflicting with it (among the already installed packages,
not all packages, but that can still be a significant number)? If you tell
dpkg to install a particular .deb, then dpkg will install it (if possible),
not some other package. Only APT will have to consider Supersedes, and it
already reads and indexes all the package lists in order to find out which
packages can be upgraded and which conflict with each other. In my view, a
Supersedes line is no more difficult to handle than the Packages entry of the
transitional package.
--
Magnus Holmgren holmgren@debian.org
Debian Developer
Attachment:
signature.asc
Description: This is a digitally signed message part.