Björn Persson wrote: > Kevin Fenzi <kevin@xxxxxxxxx> 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
Attachment:
pgpcHAXsLYVmB.pgp
Description: OpenPGP digital signatur
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
