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

Re: Using build profiles in stretch?



On Thu, May 28, 2015 at 08:43:12AM +0200, Lucas Nussbaum wrote:
> To fix #632776 (ruby-shoulda-context,gem2deb: Circular build-dependency),

That's great. Please keep that.

> This worked fine when I tested it locally because I use sbuild, but now that it
> is uploaded, I realize that:
>   - pbuilder doesn't support it (which breaks the package on reproducible.d.n)

pbuilder is maintained with NMUs, i.e. it's unmaintained. It had a patch
for an earlier version that gained little interest.

Also once experimental apt becomes unstable (whenever that happens), we
can easily add a new "apt-get build-dep foo.dsc" resolver to pbuilder
that nicely sidesteps this and future issues by reusing an external
parser.

>   - there are several other infrastructure tools that don't support it yet,
>     according to the table on https://wiki.debian.org/BuildProfileSpec

If there is no pressure, it won't happen. Also note that a few qa tools
were fixed due to the fallout of gem2deb immediately and support build
profiles now. This is a success story.

>   - it's not described in Debian policy AFAIK (see #757760)

Often policy documents practise. In my experience, it is often the case
that policy lags behind what we do. It sure needs policy, but that
shouldn't hold us off using it.

> It seems the early support in dpkg confused me into thinking that it was fully
> supported in stretch.

I'd argue it is fully supported. We just need to handle a few parts of
the fallout. Our earlier attempts at doing that during the preparation
of jessie ran afoul of figuring out the remaining issues. The only way
to find them is to try, i.e. what you did. Thanks.

> So, the question is: should we wait until stretch is released to use build
> profiles, to give time to all infrastructure tools to support them, or should
> we fix our infrastructure using backports?

Using build profiles is highly overdue. There are many places where I
have to work around the absence of profiles and there are lots of build
profile patches in the bts (e.g. #757100 #787044 #757147 #737946 #709623
#738263 #751922 #752103 #752271 #752409 #758420 #758462 #758467). More
coming any time now.

Being able to drop these patches by having them applied to packages
would be a great relief.

> Note that in most tools, it's not difficult to add basic "support" for it,
> because it only means ignoring build profiles entirely.

Yes. In my (and probably Johannes') experience, the difficult part was
discovering what needs fixing. If we were to defer using build profiles
to buster, we'd gain exactly nothing, because we won't figure out what
breaks. We'd ask the same question once stretch is released for buster.
Let's not go down that road.

Helmut


Reply to: