Russ Allbery <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>> Russ Allbery <[EMAIL PROTECTED]> writes:
>
>>> 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.
>
> I think it would be useful to advertise the optional capabilities of a
> package (noopt, nostrip, parallel) without forcing people to do trial and
> error. I suppose that's not a "require," but it certainly would be nice.
As for parallel I don't think build-options is enough. The amount of
parallelism usefull depends too much on the system and package. For
example a simple C source can build fine with -j4 and 256MB ram. But
any c++ source with templates will just swap to death with the same.
In a discussion last year I suggested providing a tool to ask the
system for the prefered parallelism to be used during compile. The
tool would get a few parameters such as what language is used or how
much ram the compiler roughly needs. It would check that against the
systems config and resources and then reply with a parallelism level
the source could use.
>> The build-arch target should be a must so no extra build option flag
>> needed.
>
> I really don't think that declaring the majority of packages in Debian
> buggy in this fashion is viable, particularly when nearly all packages in
> Debian will not benefit from this. My guess is that something on the
> order of 1% of packages have a meaningful distinction between build-arch
> and build-indep, if that, but that includes some packages that benefit a
> *lot*. Wouldn't it be better to only have to work on modifying the
> packages that will specifically benefit instead of making every other
> package maintainer in Debian add a new target that really isn't meaningful
> for their package?
Already 25% of all packages do have the targets and I assume a lot
more than 1% to benefit. If one single Build-Depends can be moved into
Build-Depends-Indep that is already a benefit.
Weigh that against the cost, adding a % to the build target or adding
'build-%: build', for the packages without meaningful distinction. I
just feel that the cost is so small that any smarter solution than
just requiring build-arch/indep tragets is more waste.
And yes, 75% of the archive would become theoretically buggy the
instance we declare it a must. But nothing breaks and nothing is
actually buggy unless the standards-version gets increased by the
maintainer. At least that is how I see it.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
