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(a)redhat.com> 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(a)chrome.pl in the afternoon and evening." - Alan Cox