Quoting Jeremy Bicha (2018-01-09 17:35:30)
> On Tue, Jan 9, 2018 at 9:07 AM, Johannes Schauer <josch@debian.org> wrote:
> > So we
> > could talk about whether we should allow more build profiles that change binary
> > package contents but so far I don't see the use case for them and thus the
> > discussion would be a bit academic.
>
> Ok, let me try to provide a more practical use case for you then.
>
> At times, Ubuntu needs to avoid certain build-dependencies because
> they would add an unwanted "universe" binary dependency to a "main"
> package. In some cases, that is the *only* change Ubuntu makes to the
> package. I believe it benefits Debian for Ubuntu and Debian packaging
> to be as shared as much as possible.
>
> https://launchpad.net/bugs/1734339
That bug references [1] which lists reason for why derivative specific build
profiles are a bad idea. Even though I wrote most of the page it is of course
not up to me whether Debian at large thinks that derivative specific build
profiles are a good or bad idea. But if you want to discuss this topic, then
here are the downsides I see:
- They are not self-explanatory. Building with nofoo active makes it clear
that the source package is built without foo. What does it mean to build
with the profile for ubuntu active, the profile for mint deactivated but at
the same time the profile for kali active? Remember that more than one build
profile can be enabled at a time. The same bug even admits that the src:git
example could be solved with a nopcre2 build profile instead of a
distribution specific profile.
- What is more maintainable? This:
ifeq (,$(filter ubuntu kali raspian steamos elementaryos, $(DEB_BUILD_PROFILES)))
or this:
ifeq (,$(filter nofoo, $(DEB_BUILD_PROFILES)))
Who maintains the list of downstreams that we support? Who cleans up the
archive once one of our downstreams is not maintained anymore? Who decides
which downstreams are eligible to be included in every package that wants
them? How do we prevent bitrot if we list all derivatives specifically?
- Learning from others: Gentoo has a similar concept with USE flags and they
also have downstreams but they do did not introduce derivative specific USE
flags.
I thus believe that the superior solution is to name build profiles after the
feature that they modify. Then each downstream can pick and choose which set of
build profiles they activate when they build packages.
Thanks!
cheers, josch
[1] https://wiki.debian.org/BuildProfileSpec#Derivative_specific_profiles
Attachment:
signature.asc
Description: signature