Dne 30.11.2017 v 16:02 Matthew Miller napsal(a):
On Thu, Nov 30, 2017 at 09:49:14AM +0100, Vít Ondruch wrote:
> Apparently, there are two camps of packagers in Fedora/EPEL. Those who want:
> 1) single version of .spec file to cover the whole Red Hat ecosystem.
> 2) clean .spec file following the latest and greatest packaging practices.
Here's my take: how much impact on the world do you want to have? Are
you doing this just for yourself, or to help other people? With that in
mind, take a look at the relative use in the world of Fedora and EPEL:
and considering the velociraptor's comment, my anecdotal sense is that
use of NAT and proxies at large institutions using enterprise distros
_probably_ makes the red EPEL line even higher.
For those of you who prefer ASCII art to graphics, here's an
approximation of this chart:
fffffffff eeeee ffffffffffff
2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017
Particularly in the last few years, Fedora as an OS is doing well. But
use of EPEL by our downstreams is growning even more dramatically. Of
course, I want Fedora OS growth, but the impact we have is _way_ beyond
that, and I'd really like us to think of _Fedora_ as beyond just the
base OS, too.
I definitely get the point, though, about it being annoying to have to
carry ancient kludges for ten years, or to not be able to take
advantage of new packaging technologies until the downstreams have
caught up. I don't discount the impact we have by making improvements
that eventually trickle down, too — we make our downstreams better with
our fast-moving development work as well as by providing a universe of
We *could* decide to just focus on one at the exclusion of the other —
drop EPEL and just work on the latest rolling release stuff. Or, we
could say that we need to dial back the packaging improvements and make
everyone focus on ecosystem compatibility.
Instead, I'd like to focus effort on bringing the stuff we need to the
enterprise distributions more quickly. And I think we need to figure
out how to make Fedora/EPEL packages on EL without needing to promise
an EL-equivalent maintenance period — that's not reasonable for many
But we can make this better. Let's work with the downstreams to that.
And, let's use automation to identify and correct problem areas.
(Hopefully not surprisingly, this is one of my top requests for the
whole Modularity effort. It should make this *easy*.)
The EPEL number you are presenting are bit unrelated number. You should
compare how many "enhancement" and "bugfix" updates were submitted in
EPEL versus Fedora (and actually you can't evaluate Fedora correctly
since there are no updates in Rawhide). In my domain (Ruby packages),
there are plenty of changes in packages in Fedora, mainly in Rawhide,
less in stable releases. In EPEL, there typically happens just one
single import and then the package stays in that state forever.
And actually, this is the biggest downside of entire EPEL, it is not
obvious if EPEL should have the most recent packages or stick with one
version forever. And while you might say that the package should follow
upstream and be updated to the same version as in Fedora, this effort
typically fails as soon as Fedora diverges too far. And then the Rawhide
developers have to still deal with EPEL macros which are not useful for
Fedora and not even for EPEL.
So I agree on the point that "we need to figure out how to make
Fedora/EPEL packages on EL without needing to promise
an EL-equivalent maintenance period". But disagree with "that's not
reasonable for many Fedora packagers.", because this is in turn not
reasonable for EPEL itself, since new versions of RHEL inherits from Fedora.