Re: new fields in debian/control
On Wed, 19 Jul 2000, Anthony Towns wrote:
> On Wed, Jul 19, 2000 at 10:52:20AM +0200, Robert Bihlmeyer wrote:
> > Branden Robinson <branden@debian.org> writes:
> > > On Mon, Jul 17, 2000 at 02:33:34PM +0200, Adrian Bunk wrote:
> > > > Successor-Of:
> > > This has been proposed many times, including by me. At one point I tried
> > > to convince Jason Gunthorpe of it. He started burning black candles, drew
> > > a thaumaturgic circle around himself, and mumbled something about it making
> > > the task apt's problem-resolver NP-complete.
>
> (Really, apt's problem-resolver is already attacking something similar
> to an NP-complete problem (I'm not sure if it is, or not, it's plausibly
> harder; installability checking is NP-complete though). AIUI, apt gets
> around this by some reasonably careful approximation)
>
> > I can't really imagine why. Apt can ATM handle multiple versions of
> > the same package pretty well. What will it matter in principle if
> > these incarnations are not called foo-1.0 and foo-1.2, but foo-1.1 and
> > bar-2.3?
>
> They're not called foo-1.0 and foo-1.2, they're called foo, with version
> numbers 1.0 and 1.2. You can only ever have one foo installed, but you can
> have both foo and bar installed (conflicts aside) if you want. They're
> different propositions. It's trivial to look up the successor to foo
> 1.0 at the moment: it's called foo, and it'll have a later version
> number. Letting that be bar 2.3 as well would make that something of a
> O(n) operation rather than an O(1) operation. What happens if both bar
> 2.3 and baz 4.5 are successors to foo? What does that mean? That you
> should install one or the other, or that you should install both? What if
> they conflict? What if two packages are successors of each other? What
> if a foo 2.3 and bar 2.3 are both available, bar 2.3 succeeds foo <<
> 2.0 and foo 1.1 is installed? Do you choose foo? bar? Both? The one with
> the higher priority? What if the new foo conflicts with something you've
> already got installed? Do you switch to bar then?
Hmm. Would it be an idea to introduce an "Alias" field? Then bar 2.3 could be
equivalent to foo 1.2, or probably better, foo 1.1.bar.2.3.
I don't know at all how apt/dpkg handle things, but package "foo" version
"1.1" could point to the "foo 1.1" structure, and "foo" version "1.1.bar.2.3"
to the "bar 2.3" structure. This would (I hope) not slow things down very
much.
Then you can't install bar 2.3 and foo 1.1 at the same time (which is
undesirable; they perform the same function, so are likely to have the same
/usr/bin/whatever program names). Double successors are impossible if aliased
version numbers are different; and if they're the same, they should be treated
just as when I'd have two different foo 1.1's available. If the "1.1.bar.2.3"
scheme is followed, packages can't be successors of each other, and both foo
and bar can come with new versions if desired (though the "successor" idea
would implicate that foo isn't available any more).
I think most of the mentioned problems can be solved elegantly this way, but
I'm sure someone will come up with new problems ;-)
Anyway, just a thought that _might_ be worth persuing...
On the other hand, if bar 2.3 has Provides: foo 1.1.bar.2.3, Replaces: foo
<<1.1.bar.2.3, Conflicts: foo <<1.1.bar.2.3, wouldn't that be an equivalent
situation...? (We do have versioned Provides, don't we?)
Regards,
Anne Bezemer
Reply to: