On Thu, 2019-10-17 at 10:52 -0400, Randy Barlow wrote: > I've always liked Gentoo's solution to "too fast too slow" > with their slots mechanism. I realized it would be good if I explained what this is in more detail for those who aren't familiar. The slot is another field on the package, and the package manager ensures that you only have one installed from each slot of a package. That's basically it. Conventionally, the slot format is often a leading portion of the package's version that users might want to be able to install side by side. Using Python as an example, Gentoo usually would use things like "2.7" or "3.6" in the "slot" field, i.e., leaving out the .z component of the version. This means users could install 2.7, 3.5, 3.6, and 3.7 at the same time, but that 3.7.0 and 3.7.1 would not be offered. Which granularity of slots are offered depend on the package and the packager (i.e., the packager makes sure the package can be simultaneously installed at the granularity of the slot, and of course also volunteers to maintain the various versions.) I like this as a user because it's presented in a simple way to me. Slotted packages don't feel any different than non-slotted packages. I use the same commands to install them as I do any other package, unless I want a specific version, in which case I just add some <>= type statement on my install command to specify which version I want (otherwise I get the default, which is typically latest available as long as it doesn't conflict with other packages I have installed.) I also like this as a packager, because my packaging experience is also pretty much the same as a non-slotted package, with the obvious caveat that I also need to make sure that the slots can co-exist. But what I mean is that the tooling and packaging file format is pretty much the same. No new things to learn, no other services. It's just another package.
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
