On Mon, 7 Dec 2015 11:32:44 +0100
Björn Persson <bj...@xn--rombobjrn-67a.se> wrote:
> Kevin Fenzi <ke...@scrye.com> wrote:
> > On Tue, 1 Dec 2015 15:46:26 +0100
> > Björn Persson <bj...@xn--rombobjrn-67a.se> wrote:
> > > 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?
>
> Other users of the GNAT toolchain? Well, if they don't use Koji then
maybe Kevin meant other distros - Debian, OpenSUSE - they all use a
buildsystem
> they can simply keep the old libgnat around, alongside the new libgnat
> and the rest of the new GCC, until XMLada and GPRbuild have been
> rebuilt. On the file level there is no problem. The library filenames
> are versioned so they can coexist. The soname ensures that the right
> one will be loaded when GPRbuild runs, and the symlink "libgnat.so"
> ensures that linking will be done with the newest library.
>
> This works on the RPM level too by the way. Two libgnat packages can
> be installed at the same time.
>
> Handling XMLada is slightly trickier. The rebuilt XMLada will have the
> same soname as the old one (unless they upgrade both GCC and XMLada at
> the same time), so they need to install it to a staging directory and
> add that directory to the search path when rebuilding GPRbuild. Then
> the old XMLada and the old libgnat will be loaded when the old
> GPRbuild runs, and the rebuilt GPRbuild will be linked to the rebuilt
> XMLada, which is linked to the new libgnat. Then they can copy the
> rebuilt GPRbuild and the rebuilt XMLada into place together, and
> remove the old libraries.
>
> With a little patch to a project file it would also be possible to add
> a suffix to the soname of XMLada. Then the two instances of XMLada
> could coexist the same way as the two versions of libgnat, and the
> staging directory wouldn't be needed.
>
> They can also get rid of the whole problem by linking GPRbuild
> statically. This seems to be what Adacore themselves do. The compiled
> GPRbuild they distribute requires only libpthread.so.0, librt.so.1 and
> libc.so.6, so libgnat and XMLada must have been statically linked in.
I would consider static linking for GPRbuild in this situation
acceptable
> > > 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.
>
> 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.
>
> Then I have some questions about that method:
>
> Why should libgnat be installed in another place? It seems to me that
> it could be in /usr/lib64 as usual, thanks to the versioned filenames.
>
> Would an explicit "BuildRequires: compat-libgnat" be needed? Wouldn't
> it automatically provide the soname as usual?
no, the binary will bring the compat library via the automaticaly
managed soname Requires/Provides
> Would someone need to manually remove the compat package from the
> buildroot afterwards? Is that what usually happens when a package
> drops a subpackage, that the subpackage lingers in the buildroot
> unless someone removes it?
no, the buildroots as created by resolving Requires and Provides, if
nothing (no binary) will use the library with the old soname, it won't
be be dragged into the buildroot
Dan
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
