11:56 a.m.
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.
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!