Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 07:58:37PM +0200, Gerfried Fuchs wrote:
> On Thu, Jul 03, 2003 at 01:49:28PM -0400, Anthony DeRobertis wrote:
> > On Thursday, Jul 3, 2003, at 07:21 US/Eastern, Gerfried Fuchs wrote:
> >> Uhm, that is somehow nonsense. How can an update of a package make
> >>itself uninstallable? What's the reasoning behind it?
> >
> > Easily. Example:
> >
> > Package: foo
> > Version: 1.0.6-4
> > Depends: libc6 >= 2.2.0
> >
> > vs.
> >
> > Package: foo
> > Version: 1.0.7-1
> > Depends: libc6 >= 2.4.0
> >
> > Replacing foo-1.0.6-4 with 1.0.7-1 would make foo uninstallable
> > (becasue there is no glibc-2.4.0 in testing)
>
> Please check the update_excuses, it would make package foo _not_ a
> valid candidate, if that happens.
That doesn't happen for circular dependencies (i.e. cycles of packages
that each depend on newer versions of each other than are in testing),
the reason being that if they weren't considered valid candidates then
such cycles could never get into testing at all. (Invalid candidates are
completely ignored - they aren't eligible for hinting, even.)
Please stop saying rude things like "Please check <foo>" to the people
who are trying to explain the state of play to you, because they are
right: it has been like this for a long time.
Example:
testing:
foo source package => binary foo (1.0) Depends: libfoo0 (>= 1.0)
libfoo source package => binary libfoo0 (1.0)
unstable:
foo source package => foo (1.1) Depends: libfoo1 (>= 1.1)
libfoo source package => libfoo1 (1.1)
Upgrading either the foo source package alone or the libfoo source
package alone renders foo uninstallable. Upgrading both simultaneously
works. The latter requires manual action (or the occasional bit of
guesswork by the testing scripts). It has always been this way.
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: