Re: again: inconsistency at the cmxa level
Sven Luther <firstname.lastname@example.org> writes:
> On Thu, Dec 09, 2004 at 07:38:01PM +0100, Goswin von Brederlow wrote:
>> Sven Luther <email@example.com> writes:
>> > On Thu, Dec 09, 2004 at 03:26:35PM +0100, Stefano Zacchiroli wrote:
>> >> On Thu, Dec 09, 2004 at 03:07:24PM +0100, Sven Luther wrote:
>> >> > Can you do checks on a non-native lpateform like m68k ? We should be able to
>> >> > get the dependencies that way, couldn't we ?
>> >> AFAICT No. Our aim is to check which packages do not link properly in
>> >> native code, how could we check this property on non-native platform?
>> > Well, to get the dependency tree. Then we know which packages needs one of the
>> > modules we know changed.
>> >> In the meantime I've tested netclient and equeue, they both need to be
>> >> rebuilt :(
>> > Yeah, maybe we should have rebuilt everything, and make a ocaml-3.08.2 Pseudo
>> > package or something :(
>> > Friendly,
>> > Sven Luther
>> On that note, you can't Build-Depend on a Provides but you need to
>> introduce a dummy package. Build-Depends on provided packages fail in
>> odd ways every now and then due to the way apt-get handles this.
>> E.g. for automake since that just happens to fail this way:
>> mrvn@frosties:~$ sudo apt-get install automake
>> Reading Package Lists... Done
>> Building Dependency Tree... Done
>> Package automake is a virtual package provided by:
>> automake1.4 1:1.4-p6-8
>> You should explicitly select one to install.
>> E: Package automake has no installation candidate
>> Anything with Build-Depends: automake will FTBFS here.
> Well, that is a bug in the auto-builders, isn't it ?
> Sven Luther
The consensus on Build-Depends has always been that they should be
deterministic and Build-Depends on provided packages are generaly not.
Since the apt team does not seem to accept the trivial patch for the
problem with uniqe provides you have to avoid them. That means
providing a dummy package instead of Provides or Build-Depending on
the actual package.