On Sun, Sep 20, 2009 at 06:16:52PM +0200, Magnus Holmgren wrote:
> On lördagen den 19 september 2009, Pierre Habouzit wrote:
> > 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?
I think either britney or dak should choke on that at some point.
> > 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:
Actually Supersedes should always be versionned I think, which is
something I missed, and make the thing pretty interesting in fact ...
> > 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'.
... especially reading that. I answered thinking you meant Supersedes to
be an alias for something complicated, not a hint for apt.
As a hint, it's probably a worthwhile goal, and I -see- ways to even
make it work for name reuse in subsequent releases. Actually with
versioning enabled, it's even quite simple.
Looking at your example, with <= in the versions instead of equality to
make it more robust,
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.5-1~)
git 1:1.6.4.3-2
Supersedes: git-core (<= 1:1.6.4.3-2~)
When a user upgrades, then /apt/ can grok that the proper upgrade path
for 'git' coming from a version <= smaller than 4.9.5-1 is using gnuit
instead. It can then just do what was suggested in another mail in the
thread and migrate "autoinstalled" flags from git to gnuit.
At the same way, the sole thing you need to prevent apt to consider
upgrading git (aka gnuit) into git (the VCS) is to make sure that the
"new" git has a strictly greater version than the package it replaces,
which can always be done using the dreaded epochs (it's ugly, but fancy
things like reusing a package name for two different things is hard, and
it's logical there is a price to pay).
So while I dismissed your idea at first thinking you wanted to make it a
dpkg thing, now that I understand that you rather want it to be an /apt/
one, it makes really more sense to me.
The point remains though that:
- apt
- dselect
- aptitude
- cupt
must support that.
I don't think in the end that britney or dak needs to grok this header
after all, as britney isn't about upgrade paths of a given package, but
rather trying to build the larger set of source packages that holds it
together, incrementally from the last result of the algorithm. I don't
see how reuse of binary packages names matters to it.
Well, so, maybe you should try to talk to apt/aptitude/dselect/cupt
guys to see what they think of the proposal :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
signature.asc
Description: Digital signature