Re: Bits from the FTPMaster meeting
Charles Plessy <plessy@debian.org> writes:
> 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.
>
> 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.
Buildds don't care about the Arch field anyway. They use P-A-S and NFU
only.
And if your package did build before then testing will have the old
package. I don't think the DAK handles the case an architecture was
dropped without manually removing the old package from testing.
So you really have not gained anything at all.
> 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.
The problem is that when you do need the package as a user it will not
be there. You probably won't even know it should be there as apt-cache
search and such won't show it.
> 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â?¦
General agreement has always been to build everything so if/when a
user needs it it is available.
The only good reason to restrict the architecture is when the package
can not possibly be build or maintained for that arch. And since you
are talking about cases where the previous uploads all did build and
worked that is clearly not the case.
> 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.
>
> Have a nice day,
The good reason for source-only uploads is to improve the quality of
packages for amd64/i386 because uploaders often do a lousy job,
i.e. too often they don't build in a clean and current sid chroot.
MfG
Goswin
Reply to: