Peter Pentchev <r...@ringlet.net> writes:
> On Wed, Feb 23, 2011 at 10:45:06AM +0100, Philipp Kern wrote:
>> On Tue, Feb 22, 2011 at 10:40:52PM +0000, Roger Leigh wrote:
>> > From discussion on IRC earlier this evening, it looks like the most
>> > pragmatic approach will be to get the apt and aptitude sbuild
>> > resolvers to strip the alternatives (after arch reduction), which
>> > will make them behave pretty much exactly like the old internal
>> > resolver, but without its bugs. This will leave maintainers free to
>> > use alternative dependencies, but like now they will be ignored.
>> > What we can do though, is make the use of alternatives configurable
>> > in sbuild, so you will be able to make use of them when building for
>> > other suites e.g. backports. This will disable the stripping.
>>
>> I find this acceptable[0]. Thanks for driving this.
>>
>> Kind regards
>> Philipp Kern
>>
>> [0] I didn't agree with the earlier suggestion of telling people to stop
>> the use of alternatives instead of using predictable behaviour on
>> the resolver side but tried to stay out of the thread.
>
> Hi, and apologies in advance if this is a stupid question or if it has
> already been discussed :)
>
> Is it possible that this should lead to problems with further levels of
> package dependencies? E.g. something like that for two packages:
>
> foo/control:
> Depends: bar-dev, libdb-dev | libdb4.7-dev
>
> bar-dev/control:
> Depends: libdb4.7-dev
>
> I realize that this is a somewhat contrived case, but still... wouldn't
> it break, or would that be considered a bug in the packages'
> dependencies? If the latter, well, wouldn't this leave the maintainer
> of foo a bit vulnerable against random decisions by the maintainers of
> bar-dev?
>
> G'luck,
> Peter
Actualy I think it is a rather common case if you ment that foo
Build-Depends: bar-dev, libdb-dev | libdb4.7-dev.
Say both foo and bar use libdb and libdb has just transitioned from
libdb4.7-dev to libdb-dev. There will have to be some coordination
between foo and bar when to transtion but given the many architectures
debian has there will be lots of race conditions.
Consider this: Both bar and foo sources have been updated to use the new
libdb-dev. On amd64 bar has already been build and has "Depends:
libdb-dev" while on armel it hasn't and still has "Depends:
libdb4.7-dev".
What we don't want to happen is that foo is now rebuild against
libdb-dev on amd64 but libdb4.7-dev on armel.
The Build-Depends alternatives must be resolved consistently the same
way across all architectures. Currently this is done by ignoring all but
the first entry after arch reduction. The ideal would be to resolve the
alternatives considering what SHOULD be in the archive and not what
currently is in the archive. But that would require some sort of crystal
ball.
On the other hand, if you did mean "Depends" and some source
"Build-Depends: foo-dev, bar-dev" then there will be no alternatives
stipping. Both foo-dev and bar-dev will be asked to be installed and
apt/aptitude will pick some combination of packages that makes them both
installable. We are only talking about alternatives in the direct
build-depends of a source. Anything below that top level, in the
indirect dependencies, still picks and chooses.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87oc5cue71.fsf@frosties.localnet
