Stephen Gallagher wrote:
Not necessarily. It may be that we have to content ourselves with
some
software always requiring a module enablement to use it. For example,
I maintain a module for Review Board, a Django-based code review tool.
For complicated reasons, it cannot run against Django newer than 1.6
(the Review Board upstream maintains the 1.6 stream of Django for
security patches). If we decide that deps of default streams are bound
to the same rules as default streams (or, alternately, Matthew's
proposal of requiring only depending on default streams), then the
necessary outcome is that Review Board can only be available via
non-default stream (since it depends on django:1.6).
The user-friendly approach for that is to use a parallel-installable
compatibility package (with a suffixed Name, such as django1.6) instead of a
module.
There's still a case that you haven't considered, which is
things that
work at runtime as a default but cannot *build* against the default
set of packages. For example, we might have packages whose buildsystem
still relies on Python 2 (WAF?) but doesn't require it at runtime.
There too, the correct approach is to provide (continue providing) a python2
compatibility package. (Even the python27 one the Python SIG has introduced
in Rawhide might be enough, actually.) There is no technical reason for it
being in a module.
There might be packages that haven't yet migrated to a new,
backwards-incompatible change to Docbook for generating documentation.
Or packages that only build properly with a newer version of golang
than shipped in that release, or any of a thousand other examples that
are easily solved by build-time-only content and dependencies in
module streams.
The preferred solution there is really to fix the package to build with the
latest version, which is the way we have always handled such FTBFS issues.
But in the worst case, we can just ship the last successful build until the
FTBFS is fixed. I think we are giving way too much importance to FTBFS bugs.
Also there are yet other packages (such as in the Go and Rust
ecosystems) that could simply be built once on Rawhide with the latest
compiler and shipped to each of the other releases without needing a
rebuild because they are statically linked. Modules allow this, basic
RPMs not so much.
As Neal Gompa hinted at, that is not a good idea because the build will be
linked with the Rawhide glibc and, as a result, typically not run on the
older releases.
Kevin Kofler