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

Re: architecture limitation question

Samuel Thibault <sthibault@debian.org> writes:

> Hello,
> Harald Jenny, le Fri 09 Jul 2010 23:41:45 +0200, a écrit :
>> I'm maintaining the amavisd-milter package and have a question: Due to the
>> unavailability of libmilter-dev on HURD (it uses PATH_MAX which is not defined
>> there) my package can't be built for this OS.

Can't you get the libmilter maintainer to fix that or NMU the package?
This doesn't sound like fixing it is rocket science.

> Then it's fine: amavisd-milter is in the BD-Uninstallable state, i.e.
> doesn't consume any buildd cpu.
>> I thought about limiting the Architectures in debian/control on which
>> amavisd-milter would run for now to linux-any, kfreebsd-any to work
>> around the failure.
> It is useless and would just make people have to request for the
> converse when libmilter-dev becomes available, while BD-Uninstallable
> already tracks that appropriately.
>> Are there any other options for temporary limiting the architectures
>> so that the build system needs not to use it's precious ressources for
>> unsuccessful build attempts?
> The buildds are keeping up quite nice nowadays so unsuccessful build
> attempts are fine.
> Samuel

And the BD-Uninstallable state means the package is not build anyway.

On the other hand limiting the architectures in debian/control has no
effect at all for buildds (or wanna-build). The relevant file would be
the Packages-Arch-Specific file. But adding a temporary entry there just
means it must be removed again later. So better not.


Reply to: