Build profile for nopcre2 build in Ubuntu

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Build profile for nopcre2 build in Ubuntu

Jonathan Nieder
(please cc me on replies, since I am not subscribed)
Hi,

Context: https://bugs.ubuntu.com/1729075

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 [1] 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[2].

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.

https://wiki.debian.org/BuildProfileSpec#Derivative_specific_profiles
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?

Thanks,
Jonathan

[1] https://bugs.launchpad.net/ubuntu/+source/git/+bug/1729075
[2] https://bugs.ubuntu.com/1636666

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build profile for nopcre2 build in Ubuntu

Jonathan Nieder
Jonathan Nieder wrote:
> (please cc me on replies, since I am not subscribed)
> Hi,
>
> Context: https://bugs.ubuntu.com/1729075

This was meant to be a link to
https://bugs.launchpad.net/ubuntu/+source/sbuild/+bug/1734339
Sorry for the confusion.

> 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 [1] 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[2].
>
> 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.
>
> https://wiki.debian.org/BuildProfileSpec#Derivative_specific_profiles
> 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?

Thanks,
Jonathan

> [1] https://bugs.launchpad.net/ubuntu/+source/git/+bug/1729075
> [2] https://bugs.launchpad.net/ubuntu/+source/pcre2/+bug/1636666

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build profile for nopcre2 build in Ubuntu

Steve Langasek-6
In reply to this post by Jonathan Nieder
Context: https://bugs.launchpad.net/ubuntu/+source/sbuild/+bug/1734339

Hi Jonathan,

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 [1] 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[2].

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

> https://wiki.debian.org/BuildProfileSpec#Derivative_specific_profiles
> 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
   https://wiki.debian.org/BuildProfileSpec#Registered_profile_names which
   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
releases.

Cheers,
--
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/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (817 bytes) Download Attachment