Re: again: inconsistency at the cmxa level
On Fri, Dec 10, 2004 at 01:04:24PM +0100, Goswin von Brederlow wrote:
> Sven Luther <email@example.com> writes:
> > On Thu, Dec 09, 2004 at 07:38:01PM +0100, Goswin von Brederlow wrote:
> >> Sven Luther <firstname.lastname@example.org> 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 ?
> > Friendly,
> > Sven Luther
> The consensus on Build-Depends has always been that they should be
> deterministic and Build-Depends on provided packages are generaly not.
Well, the way we do it, there can be only one package that provides said
virtual package, so the autobuilders could perfectly install it if they
weren't so broken. But then elmo told me "this is the way it is and it will
not be fixed" over 2 years ago now, so i have little hope of the autobuilders
doing the sensible thing.
> 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
Nope, it works fine, is an elegant solution to a real problem, and since there
is an upgrade each year only or so, the autobuilder maintainer can fix it by
hand in their control file or whatever.
> providing a dummy package instead of Provides or Build-Depending on
> the actual package.
No, this is ugly. Why is it that people always prefer ugly workarounds over
real fixes ?