Re: Can Koji handle a soname change and a self-dependency?

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

 



On Tue, 1 Dec 2015 15:46:26 +0100
Björn Persson <Bjorn@xxxxxxxxxxxxxxxxxxxx> wrote:

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

How are others supposed to handle this?

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

I'm just explaining how koji works here, don't shoot me. ;) 

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. 

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

I don't see any way to do that with the current setup. 

kevin

Attachment: pgpXSaiWNOgsU.pgp
Description: OpenPGP digital signature

--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux