general-concepts/slotting: New 'Considerations for slotting' section #363
Conversation
This is a section I've been wanting to write for quite some time and formalises a talk I've had to give many contributors. Slotting is a powerful tool but easy to abuse and there's a number of non-obvious pitfalls that we should document: attempt to do that here. Signed-off-by: Sam James <[email protected]>
|
Not done a pass for formatting yet. Looking more for feedback on the higher-level layout and missing content (I suspect there's some more which will come to me shortly). |
|
thanks for providing something we can use as a reference for people suggesting slotting |
Signed-off-by: Sam James <[email protected]>
|
I don't have anything that creates a slotted install, but slots are very helpful and I do use slotted compilers (gcc and clang) quite a bit for testing. Would be nice to have a bit more standardized way of selecting the binary for slotted commands -- for example: gcc -- gcc-config |
|
Yeah, it's worth us listing methods for the binary itself (and maybe mentioning environment variables too and For libraries: we should perhaps mention things like I should also mention that for cases where it really is a leaf package, all we really need to do is maybe have an eselect, nothing else, and those are really the ideal cases for slotting. |
or eselect gcc :) |
| </p> | ||
|
|
||
| <p> | ||
| Before proceeding at all, consider the impact on the wider ecosystem |
There was a problem hiding this comment.
Nit: you're repeating "consider the impact".
| <p> | ||
| Before proceeding at all, consider the impact on the wider ecosystem | ||
| beyond Gentoo. Especially examine other distributions and their handling | ||
| of the problem in question. Gentoo cannot unilaterally move software to |
There was a problem hiding this comment.
Well, technically speaking it can. I think the point's more like "it's not always a good idea".
There was a problem hiding this comment.
Of course, that just rather weakens the rhetoric. Can you suggest some alternative phrasing that retains some punch?
There was a problem hiding this comment.
"Unilaterally moving software can have devastating consequences for …" (users? other developers?)
| </p> | ||
|
|
||
| <ul> | ||
| <li>how does this software use this package;</li> |
There was a problem hiding this comment.
"Software" and "package" here can be ambiguous.
| Do not be fooled by the ease in adapting the package itself to slotting: | ||
| slotting the package itself is always the easiest part. |
There was a problem hiding this comment.
I think "always" is too strong here. How about
| Do not be fooled by the ease in adapting the package itself to slotting: | |
| slotting the package itself is always the easiest part. | |
| Do not be fooled by the ease in adapting the package itself to slotting: | |
| slotting the package itself is often the easiest part. |
or
| Do not be fooled by the ease in adapting the package itself to slotting: | |
| slotting the package itself is always the easiest part. | |
| Do not be fooled by the ease in adapting the package itself to slotting: | |
| slotting the package itself may well be the easiest part. |
?
| </p> | ||
|
|
||
| <p> | ||
| Before proceeding at all, consider the impact on the wider ecosystem |
There was a problem hiding this comment.
I really dislike that "ecosystem" metaphor in computing (especially in free-software) context. It is a fuzzy and ambiguous term.
There was a problem hiding this comment.
Can you suggest an alternative? In this case, I really want people to think "how is this going to affect other people", and "is there a thing this is going to break far beyond Gentoo"?
There was a problem hiding this comment.
"Before proceeding, consider the wider implications beyond Gentoo."
| be naively slotted by just adapting the package itself. Other packages | ||
| must be primed to handle a slotted world: 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 on to avoid automaigc |
There was a problem hiding this comment.
Typo:
| force building against the version currently depended on to avoid automaigc | |
| force building against the version currently depended on to avoid automagic |
| </p> | ||
|
|
||
| <p> | ||
| Ecosystems that lend themselves to slotting, such as Guile or Lua, cannot |
There was a problem hiding this comment.
| Ecosystems that lend themselves to slotting, such as Guile or Lua, cannot | |
| Systems that lend themselves to slotting, such as Guile or Lua, cannot |
| <p> | ||
| Ecosystems 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 world: an eclass mechanism usually needs |
There was a problem hiding this comment.
"World" has a specific meaning in Gentoo context, maybe better avoid?
| <body> | ||
| <p> |
|
|
||
| <p> | ||
| An <c>eselect</c> module is often made available for these cases, though | ||
| ebuilds normally shouldn't depend its use. |
| explicitly intend (major) versions to be installable in parallel. The | ||
| presumption should be that a library cannot be slotted until proven otherwise. | ||
| </p> | ||
|
|
There was a problem hiding this comment.
Is dev-java/bcprov regarded a library? If so, what' should have been the alternative to slotting in commit 901da76177 followed-up by commit 154e9224cf, all was done according to this wiki article?
There was a problem hiding this comment.
I'd say (pure) Java libraries are by construction intended to be installable in parallel (they are usually not meant to be consumed in parallel, but that is unrelated to slotting).
This is a section I've been wanting to write for quite some time and formalises a talk I've had to give many contributors.
Slotting is a powerful tool but easy to abuse and there's a number of non-obvious pitfalls that we should document: attempt to do that here.