Russ Allbery <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>> Russ Allbery <[EMAIL PROTECTED]> writes:
>
>>> Based on the arguments I've seen so far, I'm opposed to using the
>>> package's Standards-Version for this purpose. I think it conflates
>>> different meanings of that field and will get us into serious trouble
>>> when it comes to the distinctions between must, should, and
>>> recommended.
>
>> | Policy 5.6.11 Standards-Version
>> |
>> | The most recent version of the standards (the policy manual and
>> | associated texts) with which the package complies.
>
>> This field has exactly this meaning. It says the package followes a
>> certain version of policy, e.g. the one where now there is a MUST
>> instead of the previous RECOMMENDS.
>
> You seem to be ignoring the end of second sentence of my paragraph above,
> which I wrote precisely because I anticipated this argument. Could you
> respond to it as well? Not every feature we care about is going to be a
> must.
I thought you ment that with << ver something is recommended but >>ver
is is must would be a problem.
> I would much prefer to see a new control field that explicitly lists the
> supported features. We're going to need that *anyway* for any feature
> that's only a should or recommended and not a must (such as supporting
> noopt or nostrip), and making every should into a must just so that we can
> use this interpretation of Standards-Version is not a solution.
So far I have not seen anything that would require it.
The build-arch target should be a must so no extra build option flag
needed.
As for the noopt/nostrip feature. What if the source does not support
them? What can you do? Not set them? That is exatly the same as
setting them and having the source not honor them.
Having a build options flag for noopt and nostrip would be purely
informational. It is not like some functionaly gets lost wthout it
unlike the build-arch target.
By all means fight for buiold-options but I still don't see why we
need this for buila-arch/indep targets. There is no good reason to
keep the optional.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
