On Tue, Nov 5, 2019 at 3:22 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > Last week, I put out a blog post and fedora-devel thread describing > the problems that we wanted to solve with Modularity. That thread was > not ultimately as successful as I had hoped. > > My intention was to provide some scope to the problem, because it > seemed that a lot of alternatives being floated were not seeing some > of the more subtle cases that we were trying to address. However, the > biggest problem is that nearly every email to the list has been > started with a "Begging the Question" Fallacy. People have started > from the premise that "Modularity is Bad" and all of the rest of the > conversation has continued from there. I'd like to provide an > opportunity for us as a community to *constructively* state our > grievances with Modularity. The fundamental root cause of some of the > miscommunication is, I believe, that Modularity has problems and that > people have assumed that they are fundamental and unfixable. > > I'd like to gather a constructive list of the actual use-cases that > you feel Modularity is causing problems for, with the following > stipulations: Any *subjective* problems will be ignored. "I think > writing YAML is harder than writing a spec file" is an example of a > subjective opinion. Similarly, "change inevitably results in some > learning curve" is a basic maxim of innovation and is not in and of > itself an argument not to change. "Modularity requires me to write > both a spec file and a YAML file, thereby increasing the total work" > is an *objective* observation (and a valid one; I'm going to include > it below in my own starter list). If you aren't sure if it's > objective, a useful question is "is it quantitatively measurable?" > (AKA "Can I assign a number to it and see that number increase or > decrease when changing something about the implementation?") > > So, in the interest of highlighting some specific cases where the > current, deployed[1] implementation (in no particular order): > <snip because long list...> This list is fairly comprehensive, but one thing I think was missed is that we lack a policy and mechanism for making buildroot-only packages externally consumable. For example, the Rust modules in Fedora 30 actually have a buildroot-only backport of RPM 4.15 to use generated build dependencies (which is likely to be something to disallow by policy for other reasons...), meaning that the modules are published with SRPMs that literally will not work on Fedora 30. There is no mechanism to consume buildroot-only packages for package builds on those modules and so on... There's no policy that defines what cases BR-only packages even make sense (I would argue that they don't for Fedora). But in cases like this, we need a way for those packages to be available when building on top of those modules or rebuilding them. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
