On Wed, Nov 13, 2019 at 5:29 PM Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > > 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? > It was not. It was a dependency of other modules. > 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). > Could you define "broken"? Because I have no idea what you're talking about here. If it is module-only and has no default stream, it means it's effectively invisible unless you enable a stream knowingly. > >> > 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. > Again, you can't just say "it's broken" and leave it at that. Some clarity as to what you think is wrong there is critical. > (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.) > It does not implicitly ban filtering packages. It implicitly bans filtering out *sub*-packages. It still think it's acceptable to filter out *all* produced subpackages of a component that is used only at build-time. > >> 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. > This is literally the entire point of a distribution. We provide an opinionated collection of software packaged for people to use. This is no different than RPMs. As a packager, I can decide arbitrarily to ship a different default configuration than upstream does if I think it makes more sense for the users we are serving. I can opt not to build some features of a package if doing so would require pulling in a huge set of dependencies, etc. All of that is dictating the packager's preferences on our users. What you are saying is that *you* don't like what you are hearing about modules. And that's fine; some of your feedback has been constructive and we're taking it into account. But assuming that you represent the whole of the user community is somewhat of an overstatement. As I discussed in the blog post I wrote, this was designed with users in mind. Yes, we acknowledge that with multiple versions comes the risks of introducing more conflicts. We balanced that out by acknowledging that the container space is now mature enough that separating userspaces when you need to run conflicting apps on the same machine is a reasonable solution to that problem. You've asserted elsewhere that you don't like containers as a technology because it's duplication of content and doesn't espouse your view of the ideal distribution of "everything uses the same (latest) version of the library". I understand that, but containers are here to stay and Modules help us provide trustworthy content for them. Believe me, I wish that the ideal distribution was possible too. The reality is that the world has gone in a different direction and Fedora needs to adapt to that. Holding the line and refusing to budge just means people will go around us and stop considering us relevant. > 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. _______________________________________________ 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
