build-depends-indep do not get installed, when these are mandatory.

[StefanPotyra]

Hi,

soyuz fails to install build-depends-indep, when calling either binary or binary-arch.

see https://answers.launchpad.net/soyuz/+question/34821

Cheers,
    Stefan.

[StefanPotyra (sistpoty)]

btw.: where can I download the relevant parts of soyuz that call dpkg-buildpackage or debian/rules?

[LaMont Jones (lamont)]

Debian's sbuild was changed sometime ago to always merge build-depends-indep for the build-dep install, rather than just if --arch-all was specified, since dpkg-buildpackage always calls build and not build-arch (for various semi-obvious historical reasons.)

We need this in order to be able to deal with crackful packages that follow the insanity documented in policy and use build-depends-indep. :-)

lamont

[Adam Conrad (adconrad)]

After some investigation, it turns out lamont was wrong on this one. The Debian buildd don't merge build-depends and build-depends-indep, and I really don't want to gratuitously fork that functionality.

The reason I don't want to fork it is a simple one: I don't want the headache of Ubuntu MOTUs uploading a package to Debian that fails to build there, and then saying "but, but, it works on Ubuntu!"

For now, while Debian policy is still moderately ambiguous on this (because of how dpkg-buildpackage works), it's best to just say "if the build target requires it, it should be in build-depends". If the binary-indep target uses something (not the build-indep target), it's fine to have it in build-depends-indep.

Marking this as invalid.

[LaMont Jones (lamont)]

And yes, I was clearly not fully awake when I looked at the debian sbuild code this morning. The merge is done only when building archall (which is why i386 built successfully, while amd64 failed).

lamont

[StefanPotyra (sistpoty)]

Hi,

thanks for looking. (I've just seen that hs-plugins/i386 in unstable FTBFS'd for the same reason). Marking this as a bug in debian-policy hence, as either one should get fixed imho.

Cheers,
    Stefan.

[Sergio Callegari (callegar)]

Sorry for asking for clarifications here, but I am having the same issue, and I am puzzled...

Trying to build a package in my PPA, I have the build succeed for i386 and fail for amd64 and lpia.

However, the only difference I can see from the build log is that the build-depends-indep are installed for i386 and not installed for amd64 and lpia. However, if I build privately on my server with pbuilder, the build always succeeds as the build-depends-indep are always installed.

I guess that the problem is certainly in my rules, where most likely an attempt to build the pdfs necessary for the documentation is made even when it should not. I also guess that the easiest fix would be to push all the dependencies into the build-depends.

However, I wonder if someone might help me with these questions:

1) Why the behavior is different from the i386 and the other architectures?
2) Was this changed recently? The package used to build just fine on ppa, and the latest changes have not touched the debian/rules significantly.
3) Why am I not experiencing the issue with pbuilder?
4) Is there a way to have pbuilder better replicate the soyuz build systems, so that these mistakes can be catched earlier?
5) Is pushing all that is in build-depends-indep also in build-depends an acceptable solution?

[William Grant (wgrant)]

On Tue, 2010-04-06 at 09:44 +0000, sergio.callegari wrote:
> Sorry for asking for clarifications here, but I am having the same
> issue, and I am puzzled...
>
> Trying to build a package in my PPA, I have the build succeed for i386
> and fail for amd64 and lpia.
>
> However, the only difference I can see from the build log is that the
> build-depends-indep are installed for i386 and not installed for amd64
> and lpia. However, if I build privately on my server with pbuilder, the
> build always succeeds as the build-depends-indep are always installed.
>
> I guess that the problem is certainly in my rules, where most likely an
> attempt to build the pdfs necessary for the documentation is made even
> when it should not. I also guess that the easiest fix would be to push
> all the dependencies into the build-depends.
>
> However, I wonder if someone might help me with these questions:
>
> 1) Why the behavior is different from the i386 and the other architectures?

Architecture independent (Architecture: all) packages must be built only
on a single architecture, or you would end up with multiple conflicting
debs with the same filename -- one from each architecture's build.
Launchpad tells i386 builds to build architecture independent packages,
but not the others.

> 2) Was this changed recently? The package used to build just fine on ppa, and the latest changes have not touched the debian/rules significantly.

This behaviour has not changed for many years.

> 3) Why am I not experiencing the issue with pbuilder?

pbuilder assumes that you are building only on one architecture, so it
builds architecture-independent packages by default.

> 4) Is there a way to have pbuilder better replicate the soyuz build systems, so that these mistakes can be catched earlier?

You would have to look at the pbuilder manual and work out how to tell
it to not build architecture independent packages.

> 5) Is pushing all that is in build-depends-indep also in build-depends an acceptable solution?

It depends on whether they need to be B-D-I or B-D.

[Sergio Callegari (callegar)]

Many thanks, that clarifies significantly.

I will definitely look at the pbuilder doc to see if there is some hint on how not to build the arch-independent package, and if I find something useful, I might post it here, for reference just in case someone else runs into this issue. Also, I suspected that the i386 arch was treated somehow differently. However, it is quite difficult to find mention about it in the build log, which is kind of weird... is it just the "-A" passed to sbuild-package?

The strange point is the fact that this has not changed recently, since I was able to build my package in the ppa up to the previous version... might it depend on the debian policy version declared in the package? I.e., moving from 3.8.3 to 3.8.4?