On Tue, Nov 06, 2018 at 12:56:13PM -0500, Neal Gompa wrote: > 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. Suprisingly, recently I've found use for modularity. It's a crutch for bad software (OpenShift breaking backwards compatibility) but it worked. Specifically, openshift CLI command 'oc' in version 3.11 does not work anymore with cluster in version 3.7. I already downloaded rpms for previous version, and was ready for dnf downgrade + exclude= in dnf.conf when I thought about modules. And yes, there's a module with openshift-3.10. I've enabled it, installed older client and was able to access our clusters once again. And I hope to have updates and fixes provided by this module (which would be troublesome in standard exclude= scenario). That's as an user. I'm still to discover the need for modularity as a packager, but I'm not eager to. -- Tomasz Torcz "Funeral in the morning, IDE hacking xmpp: zdzichubg@xxxxxxxxx in the afternoon and evening." - Alan Cox _______________________________________________ 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
