Modularity-like packaging without modularity ============================================ Modularity organizes RPM packages in streams which are mutually exclusive inside a module. Once a stream is enabled, packages of that stream overlay nonmodular packages of the same name. That provides packagers and users with unique features for alternative package streams: (1) The alternative packages retain original names. (2) The alternative packages retain original dependency names. (3) The alternative packages retain original file locations. (4) The alternative packages do not mix with default packages of the same software. (5) Switching from default packages to alternative packages and among streams of alternative packages is always a user-initiated change. (6) Default streams takes precedence over alternative streams. (7) The alternative packages interfacing to other alternative software can be built for multiple streams of the other alternative software. This document outlines a way of packaging alternative software without modularity with current RPM and DNF5 while retaining most of the listed features. This document does not discuss other packing approaches (Software collections, compat packages, environement modules). Developing the model -------------------- I will construct the packaging model based on the above-listed features. To have the model more tangible, let's have these default packages: application | | requires V stack We are going to package an alternative stack in version 2 under a distinct package name: stack2 Distinct package names ensure that DNF will update releases from stack to stack, or from stack2 to stack2, but never from stack to stack2, or vice versa. Once a package is installed, DNF follows its updates and does not replace it with a differently named package. (Feature #4) To be able to install the application with stack2, alternative packages will RPM-provide their default names: application Requires: stack stack stack2 Provides: stack This applies not only to package names, but also to RPM Provides. Anything that constitutes a public interface of the default package needs to be replicated in the alternative stack. That enables users to install packages and refer to dependencies under the default names. (Features #1 and #2) Now we are done with RPM-level compatibility. To assure file system-level compatibility, both stacks will package same files under the same names: stack Files: /usr/bin/tool stack2: Files: /usr/bin/tool Unmangled file names enable the application to execute the tool without patching its code. The same goes for including header files, loading dynamic libraries etc. (Feature #3) That leads us to file collisions. To prevent from installing both stack and stack2 at the same time, the stacks need to RPM-conflict each to other. DNF then nicely picks nonconflicting dependencies. We could write "Conflicts: stack" into stack2. And later {"Conflicts: stack", "Conflicts: stack2} into a hypothetical stream3. But we are unable to guess what stacks would provide third-party repositories. So we come with a new, unique RPM dependency symbol (stream-stack in the following example) and abuse a less-known property of RPM and that is that reflexive conflicts to not count: Provides: stream-stack Conflicts: stream-stack Any install package having these two lines will prevented from installing another package with the same two lines. But to go further, we will move these two lines into a dedicated meta-package and all packages of the stack will depend on the particular meta package: stream-stack-default Provides: stream-stack Requires: stream-stack stream-stack-2 Provides: stream-stack Requires: stream-stack stack Requires: stream-stack-default stack2 Requires: stream-stack-2 This enables us to add multiple packages (e.g. debugger) into a stream as well as introducing additional streams (e.g. stack3) later: stream-stack-default Provides: stream-stack Requires: stream-stack stream-stack-2 Provides: stream-stack Requires: stream-stack stream-stack-3 Provides: stream-stack Requires: stream-stack stack Requires: stream-stack-default debugger: Requires: stream-stack-default stack2 Requires: stream-stack-2 stack3 Requires: stream-stack-3 Chaining all packages (stack, debugger) of a stream to the meta-package (stream-stack-default) will prevent DNF from mixing packages (debugger with stack2) among streams of the same module. (Features #4, #5). The last missing item is making default streams default. Up to now until a stream is installed, DNF is free to pick any of the stacks (stack or stack2) for the application. Weak dependencies will be used to set the preference. But there is an issue where to put the Suggests dependency. DNF only considers those which are entering an RPM transaction. That means a package suggesting a default stream must be installed from the very beginning and it must install the stream meta-package. I recommend abusing a distribution release package (e.g. fedora-release) which is in a default installation: release: Requires: stream-stack Suggests: stream-stack-default Users who did not opt for a specific stream will get preinstalled a meta-package for the default stream. Users willing to use an alternative stream at system installation will place the alternative meta-package to DNF install command line (kickstart file, @build group in Koji). Users willing to switch a stream after a minimal installation will swap the meta-packages (dnf swap stream-stack-default stream-stack-2). Users willing to swap streams while some of their packages have already been installed will need to approve the replacement with an --allow-erasing option. (Feature #6) The only drawback is one have to decide before GA which software will have an alternative content and create meta-packages for the default streams. Otherwise, users installing from GA media and upgrading later could get installed a nondefault stream. Providing packages built for multiple interfaces is possible at the expense of handling each combination as a separate stream. (Feature #7) Building alternative packages in Koji ------------------------------------- Thanks to different package names there is no need to deal with NVR clashes. Thanks to provided default package names there is no need to rewrite BuildRequires. The only known drawback is switching streams inside the buildroot. That will require a dedicated build target for each stream where the meta-package is preinstalled with "build" group (as it was done with Software Collections). Similarly "srpm-build" group can be enhanced with a build-only package delivering RPM macros easing the packaging. Another solution is rewriting BuildRequires stream-specific names: debugger2: BuildRequires: stack2 However that will work only for building packages which are not part of a minimal buildroot ("build" group) and it would require enhancing Koji to allow replacing packages when installing build-time dependenices (dnf --allowerasing builddep). That wouldn't be a regression for RHEL where modules were allowed only in AppStream repository while @build packages came from BaseOS repository. Live example ------------ See YUM repository definitinos for a proof of concept. All packages are prefixed with "test-" string to provide an isolated test environment. After enabling postmodular0 repository and installing a test-release package (simulating always installed fedora-release), you will get test-application depending on test-stack from a test-stream-stack-default default stream. After enabling postmodular1 repository, you will get an alternative test-stream-stack-2 stream with test-stack2 package. postmodular2 repository adds test-stream-stack-3 stream with test-stack3 package and test-debugger package in test-stream-stack-default stream. You can try: # dnf install test-application # dnf install test-stack # dnf install test-debugger # dnf swap --allowerasing test-stream-stack-default test-stream-stack-2 Recommended rules ----------------- Before GA define default streams: (1) Decide which software will be provided in alternative versions. (2) For those create stream--default metapackages. Each metapackage will provide and conflict with stream-. (3) Add a dependency on stream--default into each package which belongs to the default stream. (4) Require stream- and suggest stream--default from a distribution release package. Anytime when adding an alternative version: (1) Create stream-- metapackage which provides and conflicts with stream-. (2) Create packages with the software under different names. (Exact names do not matter but a consistency is welcomed. E.g. multipackage streams should use - while single package streams could use .) These packages will require stream--. These packages will provide original RPM names and provides. (3) Ask Koji administrators to create a build target with stream-- in build and srpm-build groups. Conlusion --------- It is possible to achieve a similar user experience as with modularity. The expense is an introduction of metapackages representing streams, consistent prefixing of package names, providing compat names, and an inability to introduce new modules (cf. streams) after GA. Notes ----- This document is perfect because it has 256 lines.