Re: Bits from the FTPMaster meeting
Charles Plessy wrote:
> Le Tue, Nov 17, 2009 at 08:27:22AM +0100, Yves-Alexis Perez a écrit :
>> Unless your proposal is just for unstable but doesn't want to change the
>> policy for testing migration?
>
> Hi,
>
> Testing migration works the way it should: if a package is never built on an
> architecture, testing migration is not prevented. The problem is that for the
> sake of universality, some programs are built where nobody wants them. Then
> when there is a build failure, nobody wants the ‘hot potato’. Upstream does not
> support non-mainstream arches, the porters are busy porting more central
> packages, the package maintainer has user requests to answer and knows that
> nobody will send him kudos for building the package where it is not used.
The reason we want everything to be built everywhere if possible is not
universality, but quality.
If your package FTBFS on some architecture, then that is a bug. A bug
that was already there, it just was not noticed yet. In most cases the
bug is rather easy to fix, even for non porters as most of the
architecture specific FTBFS issues are due to wrong assumptions like
32bit/64bit, little endian/big endian...
> Currently, if I put ‘Arch: i386 amd64’, in the debian/control file, it makes
> difficulties to the people who want to build the package for their own purposes
> on a different architectures, because dpkg-gencontrol will fail. If instead of this
> it would only throw a warning like ‘Unsupported architecture, use at your own risk.’,
> then the maintainer could use this field to control the list of architectures
> he is willing to support. Official buildds could then ignore the unsupported ones.
In the general case supporting all release architectures should not be
much harder than supporting only a small subset of them. Regarding the
buildds, they normally try to build everything which has more than
Architecture: all packages...
> I would be more than happy to have user feedback asking me to support more
> architectures on a case-by-case basis. But my point is that for most of my
> packages those users simply do not exist. On the other hand, as Raphaël noted,
> building everyghing everywhere is not so easy, so my conclusion is that for the
> universality of building we spend energy that could be used to improve our
> universality of using.
I think one would be surprised how many packages get used on 'exotic'
architectures. Most users don't specifically search for a piece of
software, they want to have some specific task done by using a specific
package. Not providing the package will only mean that the user either
uses another package or does not get the task done. It certainly would
not mean that a user knows before a release that they will use a
specific package nor that they would actually give feedback beforehand.
> If there is a general agreement that maintainers should be trusted and allowed
> to restrict the set of build architectures on their packages, I can have a look
> at the dpkg-gencontrol source code and propose a patch…
If there is no good technical reason, it will get built everywhere and
by extension supported everywhere.
> And to return on the topic of this thread, if we decrease the number of
> packages built by default on some slow architectures, we release some pressure
> from the build network, which makes it more fault-tolerant and removes a reason
> given to disallow source-only uploads.
Slow architectures are dying otherwise there would get new chipsets
built that are faster IMHO. So I want to look at it the other way
around: fast architectures are more fault tolerant than slow ones, so if
slow ones catch too much faults they are out for the release.
I don't think it's good to waste buildd time on failing to build packages.
I also don't think anyone is stopped from setting up a service that
allows source-only uploads as a go-between.
Cheers
Luk
Reply to: