Am Dienstag, den 16.07.2019, 12:00 +0200 schrieb Kevin Kofler:
Björn 'besser82' Esser wrote:
> Am Dienstag, den 16.07.2019, 00:20 +0200 schrieb Kevin Kofler:
> > Miro Hrončok wrote:
> > > gnutls now cannot be rebuilt:
> > >
> > > nothing provides libnettle.so.6 needed by gnutls-3.6.8-
> > > 1.fc31.armv7hl
> >
> > Don't you love circular dependencies?
> >
> > This is really the biggest issue that we have: There are more and
> > more
> > circular dependencies. Each of them is a major PITA when trying to
> > upgrade a
> > library.
>
> Here[1] is a nice example of how to break the cycle by building both
> so-
> versions in a bootstrap build.
I don't like this example, at all. This puts the burden of working
around
the circular dependency on the library, which is likely not even part
of the
actual cycle. (It just happens to be used by something that has a
circular
dependency and that hence cannot be simply rebuilt against the new
version
of the library.)
We have a circular dependency in the minimal buildroot:
systemd --> cryptsetup-libs --> json-c
cryptsetup needs json-c for LUKS2 and there is no option to disable
LUKS2 during build.
However systemd can *possibly* be build without support for cryptsetup.
The original idea of bootstrap builds was to actually break the
cycle,
e.g.,
to find a way to build gnutls without requiring gnutls itself. This
is
usually done by disabling some optional functionality in some library.
But
of course, it only works if upstream did think of the bootstrap issue
and
actually made the circular dependency optional. If all dependencies in
the
cycle are mandatory, we are stuck.
Technically I could do a bootstrap build of systemd without cryptsetup,
but that would touch a package, which does not have a direct dependency
on json-c, and thus wouldn't need to be rebuilt in any cycle at all.
But your approach of stuffing 2 versions of a library in a single
RPM
is a
really ugly hack that really should not be needed. But it is getting
used
more and more often because of a lack of proper bootstrap logic (or
of
upstream support for it).
In my conclusion I consider it to be "cleaner" to have a build with two
versions of a library for a *single* step of the whole rebuild process
involved, then to touch an unrelated package to break the dependency
cycle.
Which build chain does look cleaner, shorter, and more semantically
correct?
1. systemd (no cryptsetup) --> json-c (new so-ver) --> cryptsetup
--> systemd (with cryptsetup) --> other consumers in chains
2. json-c (double so-ver) --> cryptsetup and all other consumers
--> json-c (new so-ver)