Randy Barlow wrote:
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.
It results in a poor user experience if the combination the user needs is
then not available.
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.
Me neither, which is why I think it should just not be allowed. At the very
least, a default version of something must not require a non-default version
of a dependency that is not parallel-installable with the default version of
that dependency.
> 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.
The issue is that this complicates the package management logic
significantly (adding one more dimension to the existing 4 (NEVR)) and
brings no measurable gain compared to just suffixing the package name.
Kevin Kofler