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