Dne 23.1.2018 v 10:09 Samuel Rakitničan napsal(a): >> Dne 22.1.2018 v 12:31 Miroslav Suchý napsal(a): >> >> You took pretty basic example without context. So let me give you >> different example. >> >> There were attempts to get Ruby on Rails into EPEL. It is around 80 >> packages. Some packages were RHEL contidiontalized. But the effort to >> get Ruby on Rails was never successful. Even if it was successful, >> nobody maintained/updated it later, for example because more recent Ruby >> on Rails, developers decided to drop support for older Ruby which are in >> RHEL. That left some Fedora packages with some RHEL conditions and makes >> every update of such package pain. These conditionals won't be ever used >> again. >> >> Also, from my experience maintaining Ruby in RHEL and RHSCL, in 90 % >> percent of cases cherry-pick of the specific fix I want to get from >> Fedora works without conflicts and if there are conflicts, they are just >> in changelog. >> >> >> Vít > Well I think maintainers should chose the ideal solution for their case. If use of macros just complicates things too much, maybe use of branches might make more sense. On the other hand does it really make sense to enforce maintaining different branches for a few conditionals? Oh it definitely does. I am handling mass rebuilds of Ruby packages or updates of Ruby on Rails. This is complex task requiring touching plenty of packages. Due to update of Rails in master, I simply cannot contact maintainers of all packages and assuring their branches still works. I cannot test the .spec files on Rawhide and EPEL just because there is chance somebody is going to build the packages on EPEL. At the and, you cannot even trust the EPEL macros in Fedora. And of course every branch specific branches makes this mass changes more complicated, because you simply cannot script it. If there were no branch macros and we could consider just Rawhide doing such changes, the .spec files in Fedora would be generally i better shape. Vít _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
