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: > > https://twitter.com/mattdm/status/936243506355621888 > > 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: > e > e > e > ee > ee > eeee > eee > ee > eeee > eeee > eeee fffff > fffffffffeef fffffffffff > fffffffff eeeee ffffffffffff > fff eeeeee > eeeeeee > 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 > additional software. > > 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 > Fedora packagers. > > 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. Vít _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
