Björn Persson wrote:
Kevin Fenzi <kevin(a)scrye.com> wrote:
> So, ideally here, there's a new gcc upgrade, the gcc maintainer
> would build with a compat-libgnat subpackage that installs libgnat
> in another place. Then they build the new gcc without it. You then
> can buildrequire that compat-libgnat so you can rebuild other
> things, then finally do another rebuild without compat-libgnat to
> bring everything up on the current gcc.
If I understand this correctly, you mean that the compat-libgnat
subpackage would remain in the buildroot even after the other
subpackages were replaced with the later build. Is that right? I
always thought that when packages are tagged into buildroots, side
tags and stuff, then all the subpackages from a single source package
are added or removed together. If it's done with subpackage
granularity, then that makes things a bit easier.
I made an experiment to test this. I dropped a subpackage and rebuilt.
Once that build was available in Rawhide I tried to rebuild another
package that had a build-time dependency on the dropped subpackage. The
build failed because the subpackage wasn't found. So it is as I thought:
Each new build replaces all subpackages from the previous build, even
those that weren't produced in the new build.
Thus it seems that linking GPRbuild statically is the only solution that
is even close to practical, given the limitations of Koji. I'll
coordinate with Pavel and get to work on it.
Björn Persson