On Wed, 2019-11-06 at 01:18 +0100, Kevin Kofler wrote:
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.
This seems to be like more of a complication for the packager than for
the user, right? I was commenting on the user experience and not the
packager experience.
I agree that the packager experience does have the crazy combinatorics,
as adamw pointed out, but I discussed that in my reply to him.
You are right that the varying choices of dependencies creates
exponential growth, but modularity has conflicts too (you can't install
two modules that need conflicting dependency versions) and I don't see
a way to offer the user what we are talking about without having
conflicts.
Gentoo does have conflicts too for packages that can't parallel install
(not all of their packages are parallel installable, but they are all
generally parallel available), so they basically have this problem too.
Unless I am misunderstanding what you mean?
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).
Agreed.
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.
I'll qualify my position as not so much that I strongly dislike it, but
more that I would prefer if the package metadata could formally store
the data for me, rather than encoding it in the name.
When we encode it in the name, it's a convention, but when we store the
data in the package metadata it becomes a formal spec.
For example, in Gentoo the Python package is just called "python", and
because they know about slots, it is comfortable with me having several
of them at once:
$ equery l python
dev-lang/python-2.7.16
dev-lang/python-3.6.9
In Fedora, we obviously do this too, but we don't call the package
Python, instead calling it "python2" and "python3":
$ rpm -q python2
python2-2.7.16-2.fc30.x86_64
$ rpm -q python3
python3-3.7.5-1.fc30.x86_64
This isn't bad, per se, but I like the elegance of having the package
manager explicitly know that python-2.7.16 and python-3.6.9 are both
the same package, just different slots of it. I mean, obviously, it's
working out OK for us.
"not discoverable": How so?
I agree that the compat packages are discoverable. I will say though
that searching for "python" returning 2 results instead of 1 is a
minorly worse search experience. Minor enough that it doesn't really
bother me much.