On Wed, Oct 16, 2019 at 8:12 PM Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > > Stephen Gallagher wrote: > > 3) We need to get the policy I described above written onto -stone > > tablets- the Packaging Guidelines and then we need to go and make any > > stream that isn't compliant with it a non-default stream. > > But then we need a policy that requires a default version (non-modular or at > least a default stream) to be available. Otherwise we end up with packages > that are not installable out of the box because they have no default version > at all. > 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). That said, I'm sure that we can come up with ways to make that more discoverable, but today we have limitations with how DNF is able to do `search` or `repoquery`... it can only manage this with default or enabled streams and it doesn't "see" the non-default streams. If we go this path, I'd want to hear some input (and get some help!) on improving the discovery experience. > Matthew Miller wrote: > > How would this act in the case where a default stream depends on a > > non-default stream? > > From a policy standpoint, that non-default stream then ought to be bound by > the same rules as default streams. But allowing a default stream to depend > on a non-default stream paves the way for version conflicts to happen, so I > am not convinced that it is a good idea to begin with. > With the notable caveat of the example above, I'm willing to accept this restriction in Fedora. We just need to acknowledge that it *will* mean that some software we provide is less discoverable. If that's deemed to be a worthwhile tradeoff, I have no problems with implementing it. > > (And how would restricting default streams to only be able to depend on > > default streams change things?) > > It would solve the version conflicts issue, so it makes a lot of sense, but > at that point, why not require the default versions to just be non-modular > instead? The main argument for using default streams was that they can > depend on non-default streams of other modules. So if we disallow this > (which I think makes sense), we may as well disallow default streams > entirely and simplify things for everyone. (We would just need a short-term > workaround for the default streams that exist now. The problem would be gone > in the long run.) > 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 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. 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. So even if we eliminate the version conflicts issue by restricting what comprises a default stream, there are other benefits to module default streams. _______________________________________________ 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
