On Tue, Nov 6, 2018 at 12:26 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > As a hypothetical example, maybe python-sphinx has a major > backwards-incompatible update that becomes the default in Fedora 30. > The package you maintain will only build its docs with the older Sphinx. > Without Ursa Major, you basically have two choices: 1) Stop building > the docs until upstream catches up to Sphinx, or 2) Try to write a patch > to support the new version of Sphinx. With Ursa Major, you potentially > gain 3) BuildRequires the previous version of Sphinx for your package. So, this statement is the core of what I don't like about modularity. Pitching it as a means of allowing people to "keep back" even in packages for the distribution is bad for a distribution that pushes forward. One of the major reasons I prefer Fedora to other distributions is that we contribute to the advancement of FOSS through our developers and packagers. This goes to the extent of helping upstreams port forward and leverage new versions and new functionality. Now, I don't hate modularity as a concept, but I have personally felt that the design and approach to modules in Fedora is horribly misguided. From my perspective, it seems to be pitched as a way for Fedora to move slower, and that's not what I want from a distribution like Fedora. Moreover, as it stands, I don't think modularity provides any quality of life improvements for packagers within Fedora (it adds extra steps and makes it confusing to figure out what is maintained), and currently is a huge impairment for packagers outside of Fedora. I've brought up the issues I have with the "modularization" of things within Fedora from the context of a third-party packager, and I haven't yet seen a solution outlined with my concerns fully handled. And as I've also pointed out privately and publicly in other instances, the extra "foreign" metadata is difficult or impossible for most tools today to handle. There is some hope that those issues will be addressed, but I'm unsure if anyone cares enough to prioritize these issues. It's very clear that modules as they currently stand aren't designed for Fedora. They're designed for Red Hat Enterprise Linux. And that's not good, because we're trying to use it in Fedora. Personally, I see the value proposition for modules as such in the context of Fedora: * Providing non-default, older version packages for backwards compatibility and supporting stepped upgrade processes. Common examples of this are ownCloud/Nextcloud, OpenShift/Kubernetes, and so on. * Offering alternative variants of language runtime stacks from the system version. The tooling around modules automates the chain building process and could actually be used to generate alternate versions of language stacks very easily. This can be something like having Python 2 being managed as a module that can be built on demand for people who need it, or supporting PHP 5 when PHP 7 won't work, or something like that. What I am annoyed about is that there's been almost zero interest in actually improving the quality of life of packagers who handle the bulk of packages in Fedora, the so-called "ursine" packages (which I'm not terribly pleased about the name...). I've outlined for a couple of years now some improvements we could make here. I also continue to wonder why we aren't pushing for a merger of Koji, Koschei, and COPR to provide better workflows across the board. One of our biggest problems is that it's _impossible_ to stage any change in a suitably useful way and do things like install checks, media creation, OpenQA runs, and so on. This is the critical difference between our development process and openSUSE's, as an example. We also seem to have some kind of fear about having extra optional repositories for people to enable for non-default stuff, which is why modules are wired up the way they are (modules look like repos to the solver, and enabling and disabling them triggers that base logic). I also feel that some of the tooling we developed for modules actually would equally apply well for regular packages. For example, MBS implements a giant hack for Koji so that it's actually possible to generate a side-tag, build all the packages and their incorporated dependencies, and then export it to be included in a module. But why not adapt that model for everything else? Why not allow someone to trigger a build of something, check for reverse dependencies, include them automatically, and then build it in a side tag in the exactly correct order (as determined by the solver)? The reverse dependencies could get a normal rebuild spec bump and then have that committed to dist-git (or not, depending on how we do it!), and then merge it back into the distro after it all succeeds. The advantage of this is that if something does fail, it can be independently handled and merged into the side tag, and once all the builds in a tag are green, it could auto-merge into the main distribution tag (rawhide, updates-candidate, or whatever). And of course, building and auto-pushing for all supported distro targets is a huge simplification that would help a lot. In summary, I feel like modules as a concept makes sense, but I don't understand how the current implementation is good for Fedora as a distribution. A lot of what we've built makes a lot of sense for regular packages, so I don't understand why we don't do that. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
