Dne 30.11.2017 v 16:39 Matthew Miller napsal(a): > On Thu, Nov 30, 2017 at 04:33:07PM +0100, Vít Ondruch wrote: >> 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. > How so? I'm not counting updates — these connection counts show > repodata queries, so they happen even if there are no updates. My point > here wasn't amount of change, but number of users. For me it matters how many times I have to touch the package in Rawhide and how many times in other branches. If I have in .spec file the conditionals for older branches but in reality I don't touch them, because I don't update the old branches, then the conditionals are not just useless but harmful, because they make the .spec file less readable, they prevent automated changes in packages etc. This way we just build technical debt. > > That said, I think EPEL _and_ Fedora OS users would benefit from being > able to choose between having frequently updated Ruby packages _or_ the > "single import, stays in that state barring a serious security issue" > without having that choice be dependent on the base operating system. > > But then comes upstream which says "ah, we don't support Ruby from RHEL 7 anymore, just because we don't test it" and they put some version restriction somewhere. Then it is not EPEL or Fedora choice. This inevitably happens during the RHEL lifecycle and again, since that moment the conditions in .spec file are useless and just builds the technical debt. Vít _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
