Bug#218893: Build-Options and build-arch, noopt, nostrip, ...
On Fri, Aug 17, 2007, Bill Allombert wrote:
> > There are many requests to:
> > - gradually add support for "build-arch" targets in packages
> > - gradually require "nostrip" or "noopt" in DEB_BUILD_OPTIONS
> I am concerned with conflating this two issues which are very different
> in nature. DEB_BUILD_OPTIONS require much more flexibility than build-arch.
To clarify: this is not about having DEB_BUILD_OPTIONS in a
Build-Options field, but about declaring which options the build rules
support, so a simple list of compatibility flags, not a complex syntax.
> > 2) to document the Build-Options a package MUST and SHOULD implement in
> > the current policy version
> That does not really work: you cannot make a lot of packages RC buggy
> just by changing the requirement for a Build-Option in a new policy
> .
Exactly like for other policy changes, the requirements would only be
added if a large number of packages support the option. But the
addition of Build-Options helps in two ways:
- it gives us a metric of the number of packages implementing an option
- it permits checking whether an option will be supported -- or not,
even if this option isn't required by policy
So if you thought I saw Build-Options as a stick to force packages to
implement new features, I do not; I see it as an interface to help
packages list their capabilities.
> So once the meaning of a build-option is decided, it need to stay
> essentially fixed.
(I didn't understand this part.)
> > 3) to allow the special "standard" keyword in Build-Options to mean "any
> > option required by the policy version in Standards-Version"
>
> This make handling of Build-Options by build scripts too hard in my
> opinion. Furthermore, this was essentially opposed in the discussion of
> this bug, and I finally proposed Build-Options to address them.
I don't think this adds complexity as we can provide a
dpkg-parseoptions command wrapping the query, just like we have
dpkg-parsechangelog. I agree it adds a level of indirection, but it
would also help keep the Build-Options short if it grows.
> There were concerns that:
> 1) packaging will become more complex over time by increase in
> requirement.
If we listen to such a complaint, we wont ever add new requirements and
our packages wont ever do more than what they currently do.
Debhelper and CDBS are easy examples of wrappers helping in the
implementation of standard build-options such as nostrip and noopt, I
think we can improve these and even create new helpers, but because the
build system is flexible doesn't imply that the package writer has to
understand it all IMO.
> 2) the notion that "newer is better" will lead packages to acquire
> useless interface just because it is the most recent version of
> policy.
Why would the interface be useless? Say we require nostrip in
Standards-Version 3.8.0, why would it be useless?
> Build-Options was really meant to be at the option of the packager,
> hence the name Build-Options, and not Build-Standard.
I don't care that much about the name. :) In my proposal,
Build-Options remain at the option of the packager, and the absence of
it means "implements the build options required by the
Standards-Version".
> Policy can enforce new interfaces by itself without the use of
> Build-Options.
Yes, but it's not happening: the usual complaints is that this would
make a lot of packages RC buggy or that this places a high burden on
the packager. What I think we could improve via Build-Options:
- gather good metrics of how many packages implement an interface
- start using supported Build-Options before they are required by
policy
> > 4) to document that the absence of a Build-Options field means
> > "Build-Options: standard"
>
> Then what is the point of "standard" ? To allow package to not implement
> a Build-Options by using Build-Options: nostandard ? This seems backward.
No, the point is to have:
Build-Options: standard, nostrip, build-arch
So that it's explicit that the build options required by policy are
implemented. This is because I find it clearer than only listing
additionally supported Build-Options.
> As I said I do not like to conflate them: build-arch describe the
> interface to build binary packages suitable for the main archive
> by developers and buildd.
>
> nostrip/noopt describe ways to build debugging packages that should not
> be uploaded to the main archive. If the option is not implement, policy
> require that the package is build normally.
A lot of the discussions in #218893 and friends were on *detection* of
the build options a package supports. Even if a package implements
build-arch, the buildd will still be able to build packages in the
traditional way implemented now, so effectively "build-arch" is a build
option which everybody has, not just buildds, and that you're not
required to use when building packages, even on buildds.
I don't think it makes to have differents fields for buildds and rest
of the world.
There's a pile of build options which could be interesting for us to
list in a Build-Options field, and what I would like is simply to have
this standard way of detecting what a package supports.
--
Loïc Minier
Reply to: