Considerations for slotting

+Considerations for slotting + + +

+Slotting is a powerful tool and as such, is easily abused. It's critical +that when slotting, package maintainers carefully reflect on implications +for reverse dependencies. +

+ +

+Do not be fooled by the ease in adapting the package itself to slotting: +slotting the package itself may well be the easiest part. +

+ +

+Before proceeding at all, consider the wider implications beyond Gentoo. +Especially examine other distributions and their handling of the problem in +question. Unilaterally moving software can have devastating consequences for +both users and other developers. +

+ +

+Suppose every possible consumer of a slotted package can be adapted in +Gentoo: there is still more work to be done. Keep in mind that users may +develop or test software on Gentoo systems which may be deployed elsewhere. +They both want to be able to build that software without having to adapt to +Gentooisms, and they also don't want to unintentionally write their software +such that it relies on Gentooisms. +

+ +

+For example, slotting software by inventing a Gentoo-specific pkgconfig +file and then patching all packages in the Gentoo repository is usually +the wrong decision, because users won't be able to build software manually +without patching it, and they may ship software that then fails to build +on other distributions. +

+ +

+Even systems that lend themselves to slotting, such as Guile or Lua, cannot +be naively slotted by just adapting the package itself. Other packages +must be primed to handle a slotted landscape: an eclass mechanism usually +needs to exist for packages to declare which versions they support, as well +as force building against the version currently depended upon to avoid +automagic dependencies. +

+ +

+For example, for slotted Guile, it may be trivial to make dev-scheme/guile +itself install itself as guile-3.0 (and other -3.0 suffixes +on its binaries), but packages depending on Guile will need an eclass to +control which Guile the installed files are compatible with. +

+ +

+All reverse dependencies of a package should be tested and examined when +considering any slotting approach, in particular asking the following: +

+ +

how does this software use the to-be-slotted package;
how the build system should locate the (right) version of this package;
+ how the package (and the right version of it) should be located at runtime, + if required. +

+ + + + +Libraries + + +

+As a rule of thumb, libraries should not be slotted unless upstream +explicitly intend (major) versions to be installable in parallel. The +presumption should be that a library cannot be slotted until proven otherwise. +

+ +

+If a library is to be slotted, please consult with upstream wherever possible: +ask them to begin installing pkgconfig files to aid porting build systems +to detecting the library portably. +

+ +

+ABI should also be considered with slotted libraries: if a consumer of the +library (in)directly links against another version of the library, loading +two ABI-incompatible versions of the library in the same process, unpredictable +runtime behaviour may occur (including crashes, or worse). +

+ + + + +Executables + + +

+For utilities / executables, slotting may be acceptable as long as an +unversioned, generic symlink or wrapper is made available for the benefit +of user scripts or tools, and build systems which expect the generic name +to be available. +

+ +

+An eselect module is often made available for these cases, though +ebuilds normally shouldn't depend on its use. +

+ + +