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)
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
