On Thu, 2019-10-17 at 03:53 +0200, Kevin Kofler wrote: > The user-friendly approach for that is to use a parallel-installable > compatibility package (with a suffixed Name, such as django1.6) > instead of a > module. I've always liked Gentoo's solution to "too fast too slow" (which has been around for what seems like more than 10 years, though I'm not sure the exact date they introduced it, so let's just say "a long time") with their slots mechanism. Their packages just have another metadata field that is called slot, and typically corresponds to a portion of the version that indicates how granular the packager wants to go with parallel availability (and in what seems like all cases I've noticed, they also have parallel installability, though I'm not confident enough to claim they offer that for all packages without verification). For example, I have Python 2.7 and 3.6 one one of my machines, but it's not called python2 and python3, both are just called "python": $ equery l python dev-lang/python-2.7.15 dev-lang/python-3.6.5 And all Python packages I install don't need python2- or python3- prefixes, they can just use their normal names and Gentoo does the right thing based on which Python versions I have installed. It actually doesn't even install n versions of each Python package, just one that determines which Pythons you have and just gets installed for those versions. It's great. rPath's Conary also had some of these concepts (and had my favorite packaging format that I've used - your "spec file" is just a Python class. No DSL, and you can take advantage of inheritance to make pretty simple and clean spec files!). Why not just stand on the shoulders of giants and add a "slot" field to the spec file? Then you can have everything be regular RPMs. No complicated build services to figure out. It's simpler. I've also wondered why we didn't take a queue from NixOS, which seems to have also solved these problems a long time ago in an even more advanced way than Gentoo did. It'd be a bigger change than using slots, but I think it'd be even more advantageous. Are we re-implementing something that's been solved by others before instead of joining them upstream? We aren't solving the "too fast, too slow" problem no matter what we do, because it was already solved long ago by others. Why not just benefit from their efforts and adopt their technology and experiences to Fedora, rather than doing it ourselves? Isn't that the advantage of open source software?
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
