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

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

> 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

> > 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: