Randy Barlow wrote:
> I haven't used Nix before, so I can't comment on that one, but in what
> way would Gentoo's solution require a substantial user experience
> change? When Gentoo added it, the only user experience change for me
> was when I wanted to pick a non-default slot (or as we call it,
> stream). If I wasn't doing that, things just kept working they way they
> had for years before that. It's still like that to this day - I only
> have to know about Gentoo slots if I am trying to opt-in to some
> version that isn't the default (the default in Gentoo is typically the
> latest stable version). Actually, even if you don't opt in you are
> likely to end up with a few packages parallel installing due to
> dependencies pulling in different versions of things.
The big difference is that Gentoo is source-based, whereas Fedora is binary-
based. So where Gentoo needs to ship only one ebuild (the equivalent of a
specfile) for foo-1.2.3 that the user can then compile against different
choices of dependencies, we need to ship binary RPMs of that same foo-1.2.3
version for each and every combination (exponentially many) of dependency
versions that we want to support. Which is one of the unsolved issues with
our Modularity implementation, too.
One solution would be to pick one combination of dependency versions and
rely on parallel installation of the dependencies, but for that, we need not
only a stream system, but also the file system layout tweaks of the
parallel-installable Gentoo slots. For parallel installation, there are
really only 2 solutions:
1. manually tweak things per package in the least invasive possible way
(e.g., installing headers to /usr/include/qt5 rather than just
/usr/include), as already done in compatibility packages, or
2. use a custom prefix under /opt, as is already done in SCLs.
I think 1. is by far superior (even though it is more work), and AFAIK, FPC
and FESCo mostly agree: in fact, Fedora ships packages that do 1., but not
packages that do 2. (SCLs have basically been rejected in Fedora).
langdon wrote:
>> * compat-libs (or compat lib style): not discoverable, name mangling
Randy Barlow replied:
> Yeah I don't love this either.
I don't understand why people dislike compatibility libraries so much.
"not discoverable": How so? If you search for foo in Dnfdragora, you will
automatically also find foo1. How is that "not discoverable"? In addition,
compatibility libraries are usually used for non-leaf packages, which in
most cases you don't want to install directly, but instead, whatever you
actually want to install will automatically drag in the correct version. So
there is nothing to "discover" in that case.
"name mangling": Why is this a problem? First of all, it is not mangling, it
is suffixing. The original name is retained unchanged and nothing is
prepended to it, only appended. And, e.g., Qt 3, 4, and 5 are all different
packages, so why should they have the same package name? I can understand
people complaining about "mangling" if you do things the Debian way and
append an soversion (not a human readable version, so the KDE 3 libraries
end up as kdelibs4 and the KDE 4 libraries as kdelibs5!) to all libraries
(even the default version), but that is not how compatibility libraries work
in Fedora.
I think that compatibility libraries are the much cleaner solution than any
stream-based approach, be it module streams or Gentoo slots.
Kevin Kofler
_______________________________________________
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
