Dne 30.11.2017 v 17:32 Stephen John Smoogen napsal(a): > 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). What I really want to answer is the question in $SUBJECT, since the scope of guidelines is not specified anywhere. It seems that FPC itself does not know what releases they target and my guidelines update [1] is stuck in review just because of this. The packaging style is very related of course. If the philosophy of Fedora/EPEL was "every change goes into every branch" then the guidelines should probably cover all the branches and discuss all the differences. But the update policy [2] says the opposite: "we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience". So saying that majority of people supports all the branches is against the policy IMO. Also, if the guidelines covered all the branches, the probably Rust guidelines would not be approved yet ... V. [1] https://pagure.io/packaging-committee/issue/710 [2] https://fedoraproject.org/wiki/Updates_Policy#Philosophy _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
