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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
