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.
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.
> (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.)
Kevin Kofler
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
