On Fri, Dec 08, 2017 at 12:47:44PM -0800, Jonathan Nieder wrote:
> In Debian, occasionally a package needs different build-time
> dependencies per target environment, due to missing packages, behavior
> differences, or other reasons. Most of the time, developers don't run
> into such issues, but when they do, they're able to resolve them using
> arch-qualified build-depends. sbuild respects arch-qualifications so
> this results in a working build on all relevant arches.
> In  I ran into a similar issue: Ubuntu is not able to use the git
> package from Debian because
> - in Debian, the package uses Build-Depends to allow builds against
> pcre2 and older pcre. The first alternative is pcre2, so that is
> what Debian uses (good). In backports, pcre2 is not available so
> it falls back to the older pcre (also good).
> - Ubuntu has pcre2 but it is not part of main.
> So Ubuntu patches the package to build against the old version of
> pcre. That alone would be fine, but it results in the package in
> Ubuntu falling out of date. I would like to update the package in
> Debian to be usable in Ubuntu as-is to prevent that happening.
> If I could use
> Build-Depends: libpcre2-dev <!ubuntu> | ...fallback...
> then I'd do that and be done.
> discourages this application of build profiles and says to prefer
> something distribution-agnostic like "nosystemd". Fair enough: if
> I could use
> Build-Depends: libpcre2-dev <!nopcre2> | ...fallback...
> then I'd do that and be done.
> Sensible? Any downsides I'm missing?
The downsides I see to this approach are several and significant.
- The namespace of build profiles is effectively unmanaged, aside from
describes itself as a "prospective list". And also specifies that
profile names are a "distribution-specific policy". This does not lend
itself to consistent semantics between Debian and Ubuntu.
- "pcre2 is not part of main" describes Ubuntu at a single point in time
and for a particular set of Ubuntu releases. It does not represent a
fixed policy for "all releases currently built in Launchpad", and when
pcre2 does eventually supersede pcre in main, this will happen only for
later releases of Ubuntu - not for all releases that need to be buildable
with a given deployment of sbuild on the Launchpad autobuilders. This
makes encoding this information in sbuild awkward and unnatural.
- Launchpad is also used to build software that is not part of Ubuntu
proper; personal package archives (ppas) are used to build a lot of
packages without regard to what is supported in Ubuntu main. Requiring
users to care about build profiles in order to enable pcre2 for a package
in main seems like an unnecessary indirection.
The traditional solution to this problem is to provide some sort of
metapackage or virtual package to use as a build-dependency, and have this
point to the implementation of choice in each distribution. I think the
traditional solution here remains the best solution.
As an aside, your assertion in
https://bugs.launchpad.net/ubuntu/+source/git/+bug/1729075 is that having a
delta has led to the package being out of date. While it's true that the
package is currently out of date in bionic, bionic is currently in
development, and we would normally expect to see this package updated at
some point before the next stable release in April as a matter of course.
And with regards to Ubuntu 17.10, the single version that was uploaded to
Debian unstable prior to Ubuntu feature freeze, and not merged into Ubuntu
for artful, is git 1:2.14.1-2. I don't think this strongly supports the
notion that the delta is causing a drag on package currency in Ubuntu
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/