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.
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
