diff --git a/general-concepts/slotting/text.xml b/general-concepts/slotting/text.xml index 767238ad..c3d8e96f 100644 --- a/general-concepts/slotting/text.xml +++ b/general-concepts/slotting/text.xml @@ -159,12 +159,68 @@ of user scripts or tools, and build systems which expect the generic name to be available.

+

+For autotools-based packages, the --program-prefix, +--program-suffix, and --program-transform-name + +options options may be helpful. +

+ +

+New slots are usually incompatible with older versions in some regard like +UI, syntax, behaviour. A new version of a slotted executable could suddenly +break users' workflows, so a +news item +or +ewarn +may be appropriate. +

+ +

+Depending on the level of incompatibility, a separate package may be +more appropriate to avoid breaking scripts, cronjobs, and so on. +

+ +

+For example, app-containers/docker-compose in SLOT="0" installed a +standalone executable, while SLOT="2" installed a helper outside of +PATH which is no longer accessible to scripts. A separate package +may be more appropriate for such a case. +

+

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

+ + +Separate package + + +

+If a prospective newly-added slot would have a +blocker +(possibly because of file collisions) on another slot, using the same slot +or creating a new package may be more suitable instead. Users generally +expect slots to imply each can be installed in parallel. +

+ +

+Such new packages are usually in the same category and have the same +package name but with a number or other suffix. +

+ +

+An advantage of a separate package is that maintainers won't be tempted +(or prompted by pkgcheck) to clean up old versions which are shadowed +by newer ebuilds. A similar concern exists for stabilization where tooling +will prompt developers to stabilize a new version when both the old and new +versions may be intended to co-exist indefinitely. +

+ +