-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thu, 2017-11-30 at 09:49 +0100, Vít Ondruch 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'm one of these people too. > > 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. If we want to have compatibility, then we need to improve RPM (e.g. by introducing new macro). All ruby/python/nodejs/rust packages look same, except for versions and some special hacks for packages. Tibbs and Panu were proposing some ideas how to make it better, so probably we should look into that direction. > > Vít > > > > [1] > https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.o > rg/message/QDQ42LRLCP5NOIFSAMUDMP6ZUH3AAHKN/ > > [2] https://bodhi.fedoraproject.org/updates/?user=vondruch > > [3] https://pagure.io/packaging-committee/issue/710 - -- - -Igor Gnatenko -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlof29IACgkQaVcUvRu8 X0z38A//Upax+T95Mgw6nHOug1rC9zeGat5Rc5tYKTmheJlCLTeBV7blXTNhHDG3 8sjYqox1cq9t9ouz+MQ5V37Y0ArVONKA0PI9lVVc88JKjFkwCSiaJEMqNAJZTapN dJbixuU5YQktleX6YaRjI2onets24U7wDQlsUn3TLaYufR6YotNJPq+zhG+HTnmR O74C+N57HEL2byGDIYJuf5fXFdWKVdX954tjMS0dXDJTe5pri7636dkEbqe5H3E2 SgsAVxN8cmBM02Wi6l2KyjwpDqK8Z9jQSd29jeqDnQGDK+9x6oA7HVrXdTeO5oBA jgwjP5/ue7TeNQz16LI6BMrehaxU4hluIAJ7SWc4dQ4uCQqcJ1FdbGz3BAd+5JT9 77Lg3XImG+rzTWhPnR+yTEDCXbdabiJNmau4TJPbtxfY8UeWRX4TvippZO6CVrVc IgpNuwyA0dWQKJ80RVC4FPpg2sVyjFkl0BooGQsh6nttpDMFMmwUnJUYQs3s1egL 42CGTzWjIaW6IgvfJYD5Qkz05zjM6VOBA+AmaHbtHfGTLv7BN5WStctA4kEIOb76 PpQeU6MIcc1NsPA+TLSr76i6DbeO7hx570OAOI6QxtqIrKceZu+iiZaG6qh73V/H 1Ev6wnvtZ7BrQBSM/SlbXbucU6vF8WlSqkuR1yScLjoDsbsLaIc= =NURy -----END PGP SIGNATURE----- _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
