Re: How to specify architectures *not* to be built?
At 16:01 +0200 8/10/02, Russell Coker wrote:
>On Sat, 10 Aug 2002 12:19, Geert Stappers wrote:
>> At 16:32 +0200 8/9/02, Matt Zimmerman wrote:
>> >On Fri, Aug 09, 2002 at 04:08:46PM +0200, Andreas Rottmann wrote:
>> >> I have one package (radvd) that builds only on Linux (and the *BSDs),
>> >> but not on the Hurd. How dow I specify that arch requirement in the
>> >> control file? Policy D 2.3 seems to indicate I can only sepcify a list
>> >> of supported archs, which is not what i want. I would like something
>> >> like
>> >>
>> >> Architecture: !hurd-i386
>> >>
>> >> is this possible?
<sarcastic>
Sure it is possible.
It is also possible to shoot people in the foot,
it will make them cripple in a quick way.
</sarcastic>
Read on
>> >
>> >This is not currently possible. You must list supported architectures
>> >explicitly if not using 'any' or 'all'.
>>
>> Having an "NOT arch" is IMHO evil.
>>
>> Tell what is supported, don't tell what you discriminate.
>
>If you make a list of things you support because you don't support one
>particular architecture, then when new architectures are added your package
>will not list them (and the auto-builders won't even try building it).
>
>Wheras if you declare that you don't support the one platform you know has
>problems, then when new ports are added at least you'll find out whether your
>package compiles.
My message is
"Keep the architectures 'all' or 'any', don't narrow your vision"
If a package doesn't build on an other architecture,
it wouldn't go away by an, example given, "Architecture: !hurd-i386" message.
When the cause of the buildproblem is a missing library,
then the problem will be fixed by adding the lib.
The "NOT arch"message will still cripple the packages.
When the cause of the buildproblem is in the package, fix the problem there.
The package maintainer hasn't to do it by himself,
he can/must/should cooperate with people of other architectures.
A sign like "!hurd-i386" looks to me like "No niggers allowed",
it is not an invitation to cooperation.
Making life easier for the auto-building software
by adding a discriminating test on architecture doesn't make sense,
there has still checking/handling for build failures.
I don't expect that a single maintainer supports all architectures.
It is nice that he tries other archs and reports buildfailures,
but it is wrong if he blocks an architecture.
A list of supported architectures has to be updated when a new arch arrives.
In _all_ packages....
"Keep the architectures 'all' or 'any', don't narrow your vision"
Geert
Reply to: