[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: First steps towards source-only uploads



Hello,

2014-08-13 22:59 GMT+02:00 Philipp Kern <pkern@debian.org>:
> On 2014-08-13 14:34, Raphael Hertzog wrote:
>> On Wed, 13 Aug 2014, Colin Watson wrote:

>>> I don't think there's a good reason to build them separately, and some
>>> good reasons not to (for example, it would waste a good deal of buildd
>>> time for a number of packages without very hygienic separation of their
>>> build rules).  My suggestion would be to just build them along with the
>>> architecture-dependent binaries for some nominated architecture, which
>>> could be package-specific or not depending on what you all have time
>>> for, and be done with it.

>> In kali, that's exactly what I have been doing. Any package that builds
>> an arch: all is sent to an amd64 buildd and sbuild on the amd64 buildd
>> gets
>> called with -A.
>>
>> It doesn't matter whether it builds only the arch: all or another package
>> too.

> We need to convey if the arch:all is actually needed, though, otherwise dak
> will reject the package. Or could we simply build it always and have it
> discarded if the maintainer's copy had been accepted?

Even building arch:all packages in one architecture might solve the
issue, I do not like that approach, as it holds other arches from
building until that "primary" arch has built arch:all packages. It
also leads to not fully buildable packages for the rest of
architectures, i.e. #690260 (openjdk-7: build empty doc packages on
arm).

Building arch:all on every architecture can also be seen as a waste of
build time but effective.

Another approach would be to find out if arch:all packages are
available for build, if not, then build them along package in
whichever architecture, otherwise skip them. That looks the most fair
approach to me, but it can possibly lead to interesting races,
depending on implementation.

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


Reply to: