On 30 November 2017 at 03:49, Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > Hi all, > > Reading logs from yesterdays FPC meeting [1], I think we should discuss > what is actually purpose of packaging guidelines and which version of > Fedora/EPEL/RHEL they actually targets. > > > 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. > > > I personally belong to the group (2) and that is for several reasons: > > a) I use Rawhide on daily basis and I develop only for Rawhide. If I do > changes in older Fedoras, then it is typically just bug fixes and > honestly, that does not happen often (I am POC of ~200 packages and I > submitted just 40 updates during last year [2]). And in fact, this is > official philosophy of updates [3], not just mine. > > b) I spent time developing features which should simplify packaging (for > example in F27+, the RPM %setup macro can expand the .gem packages) and > I want to use these technologies to simplify my life and life of others. > > c) As a proven packager and person who typically does rebuild of Ruby > packages, I really hate the branched .spec files where nobody knows what > was the purpose of the branches, most of the branches are for obsolete > and unsupported releases etc. It is quite hard to apply any improvements > into such packages. Moreover it is not realistic to test them. If they > were maintained, it would be different story, but the reality is different. > > > Don't get me wrong, I understand that there are packagers who has just > handful of packages and it is better for them to maintain just single > .spec file with all the branches and I don't mind them as long as the > packages are really actively maintained. But this approach just don't > scale and should be exception and not recommended practice. > > > To sum this up, my take on packaging guidelines is that *the guidelines > should document the most recent practices available in Rawhide and this > should be documented*. Covering all the exceptions necessary for older > Fedoras (not even mentioning RHEL/EPEL) makes the guidelines unreadable > and what is worse, they slow down entire development of Fedora. > Honestly, I think the RHEL/EPEL part of your conversation is a Red Herring (aka not the real point). You are wanting people to follow your method of packaging everything because it makes your job easier. The problem is that other packagers want you to follow their method and that makes your job harder. EPEL versions stand out like a sore thumb of wanting that but even the differences between getting something working in F25 and F28 can be quite a bunch of %if strings which makes your job harder. On the other hand, other people aren't interested in Rawhide and want all that. The problem is an age old one and one that comes up after every couple of releases. I think the EPEL group have tried a lot of different solutions which try to help on this 1. If a package is not maintainable to the developer, stop maintaining it. At the moment, it will be removed from usage. People wanting it can get it from various archives. 2. Tibbs has gone through several herculian efforts to backport as much of the new FPC macros and such to older EPEL's so that newer schemes can work. 3. We are open to suggestions of what maintainers and developers want or do not want out of the repository. > > Vít > > > > [1] > https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx/message/QDQ42LRLCP5NOIFSAMUDMP6ZUH3AAHKN/ > > [2] https://bodhi.fedoraproject.org/updates/?user=vondruch > > [3] https://pagure.io/packaging-committee/issue/710 > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
