Aleksandra Fedorova wrote:
1) there are exactly 6 default streams in Fedora rawhide
dwm
avocado
scala
ant
gimp
maven
and eclipse is being discussed.
What about libgit2, was that not a default stream?
And what we are missing here is a list of modular packages with no default
version at all (i.e., neither an ursine build nor a default stream), a state
which is completely broken (but which seems to currently exist in Fedora,
unfortunately).
> > Anyway, default streams is just one side of a story. It did
get into
> > the critical path of Fedora and did create upgrade problems and
> > certain UX issues, but I think we can restrict and resolve it.
>
> And what is wrong with the obvious solution, which is to just not use
> default streams at all?
The "obvious solution" does not solve anything for the Java stack in
Fedora and four Java modules currently having default stream.
So I guess the proposal is underspecified. What I really propose, and how I
read Miro's proposal as well (Miro, please correct me if that is not what
you intend), is that 1. any package that exists in a module MUST have a
default version and that 2. that version MUST be packaged in the ursine/non-
modular repository, not as a default stream.
Point 1. is essential, as otherwise, point 2. alone will just lead to people
not declaring a default version at all, which is a completely broken state
and so even worse than the situation with the default stream, despite all
the issues with default streams.
(Please note that I also read those 2 points as implicitly banning filtering
packages from modules, but if that is not obvious to someone, then it should
be added as a separate rule.)
> Why can the default version not be shipped in the
> tried and true non-modular way, so that people who do not need or want
> modules are not forced to use them against their will?
This is a question to package maintainers who want to enable the default
stream. But by using your "will" as an argument against their "will"
we
are not going anywhere in this conversation.
We should cater to our users' needs, not let a handful individual packagers
unilaterally dictate their personal preferences to thousands of users.
There are several practical reasons for not wanting to use modules, as I
have already mentioned elsewhere in this thread. Please read my other
replies, I do not want to repeat myself.
Kevin Kofler