Re: Buildd & binary-indep
- To: Russ Allbery <firstname.lastname@example.org>
- Cc: email@example.com
- Subject: Re: Buildd & binary-indep
- From: Goswin von Brederlow <firstname.lastname@example.org>
- Date: Wed, 06 Oct 2010 09:04:46 +0200
- Message-id: <[🔎] email@example.com>
- In-reply-to: <firstname.lastname@example.org> (Russ Allbery's message of "Thu, 30 Sep 2010 14:06:00 -0700")
- References: <20100925192225.GA5350@nbw.dhome.lan> <20100925195951.GD2380@jamessan.com> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20100927094044.GA31783@pcpool00.mathematik.uni-freiburg.de> <20100927122720.GB18728@rivendell.home.ouaza.com> <firstname.lastname@example.org> <20100927204819.GB23290@rivendell.home.ouaza.com> <email@example.com> <20100930195603.GA19483@rivendell.home.ouaza.com> <firstname.lastname@example.org>
Russ Allbery <email@example.com> writes:
> Raphael Hertzog <firstname.lastname@example.org> writes:
>> Well, we specified DEB_BUILD_OPTIONS space separated because build flags
>> frequently embed commas. Shall we not take the same decision
>> preemptively here?
> Most fields that take multiple values use commas. We do have another that
> takes spaces (Architecture), but I would much rather use commas.
> If the field is space-separated, it can't be folded. If you want it to be
> folded, it has to be comma-separated (unless you're proposing introducing
> yet a *fourth* syntax for control fields, which seems like a bad idea).
>> Also if we want to have lists as values for some "features" â?? like
>> "disable-hardening=pie,relro" â?? we'd be better with using space
> I think that would be a bad idea. If we need to provide data that takes
> additional options, we should add another field, since we already have a
> syntax for that. Not add key-value pairs inside the value of something
> that's already a key-value pair.
Do we need this in debian/control?
Why not debian/source/options or debian/source/hardening if it is a more
special feature that requires extra args?
I wouldn't even mind putting the "build-arch" flag in there too. Dpkg
already has options in there that affect how packages are build (e.g. I
use it to ignore the ccache dir when building the source package so it
can be kept across clean calls). That wouldn't require any policy
change, maybe that would make progress possible.