Kevin Fenzi wrote: > On Sun, 29 Nov 2015 00:35:37 +0100 > Björn Persson <Bjorn@xxxxxxxxxxxxxxxxxxxx> wrote: > > > Is there a way to deal with the following situation in Koji? > > > > · Build tool B has a build-time dependency on itself. > > · B is linked to library L version 1. > > · L gets upgraded to version 2, which changes its soname. > > > > B needs to be rebuilt to link to libL.so.2, but building B requires > > a working B, which requires libL.so.1 because it hasn't been rebuilt > > yet. > > > > As I understand it, when the L-2 package goes into the buildroot it > > immediately replaces L-1. Is there a way to keep L-1 available > > until B has been rebuilt? > > Nope. > > > Is the answer to link B statically? > > Nope. > > The usual way to handle this is to add a compat version of the library > (so.1) to L, rebuild B, then drop the compat library, ie just keep it > for one build to rebuild B. So the L source package shall temporarily contain two versions of the source tarball and build them both, and then install one as usual and extract only the binary library from the other? That would complicate the spec quite a bit even in an otherwise simple package, and when the spec is already big and complex ... Time to get specific. L is libgnat, a subpackage of GCC. B is GPRbuild, the builder that builds the Ada packages. GPRbuild is linked to XMLada, and both GPRbuild and XMLada are linked to libgnat, as are all other Ada programs and libraries. With every major GCC upgrade the soname of libgnat changes, and all the Ada packages stop working until they get rebuilt. But rebuilding requires a working GPRbuild. Previously a catch-22 was avoided because XMLada and GPRbuild were built with Gnatmake, which is built as a part of GCC. Now they're both built with GPRbuild instead, and Gnatmake is emitting warnings that it's going to lose support for the project files that control the build. The next GCC upgrade will make the problem acute. So now you're saying that the GCC package, whose spec is already 3000 lines long, needs to contain an entire additional GCC and build large parts of it, just to work around a limitation in Koji? I can of course ask the GCC maintainer, but I fully expect that he'll refuse. And then XMLada must be rebuilt before GPRbuild can be rebuilt. This XMLada build will have to provide a compatibility instance of XMLada linked to the old libgnat, because otherwise both versions of libgnat would be loaded into GPRbuild the next time it runs. For that to be possible, the compatibility version of libgnat must include not only the binary library, but also the old version of the entire content of libgnat-devel, so that the compatibility instance of XMLada can be linked. That in turn means that the old version of the compiler itself must be provided, because GNAT performs consistency checks and won't link code compiled with one version of GNAT to a library compiled with another version of GNAT. In short, this seem like an enormous amount of trouble, mostly in the GCC pacakage. It would be so much easier if the already existing libraries could remain available for a limited time. Björn Persson
Attachment:
pgpFiBG51xolX.pgp
Description: OpenPGP digital signatur
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
