Dne 21.7.2017 v 00:24 David Sommerseth napsal(a): > On 20/07/17 12:47, Michael Schwendt wrote: >> On Wed, 19 Jul 2017 13:27:54 -0400 (EDT), John Ellson wrote: >>> This works well for me, upstream, for building and testing across all distributions, but perhaps the .spec file is less optimal when you separately maintain versions for each distribution? >>> >> Doubtful. It's a maintenance nightmare. Tons of defines and conditionals, >> which toggle almost everything (BR, features and subpkgs) using highly >> cryptic macro names, sections that don't adhere to the packaging >> guidelines, dangerous violations of the guidelines, workarounds for RHEL >> 7. You may be familiar with the spec file, or you may believe you are, but >> in my point of view, the spec file is filled with pitfalls. That will >> backfire eventually. Not even the %changelog has been maintained since >> 2009. And probably the biggest mistake related to conditional subpackage >> builds is that you cannot simply flip a #define and disable a subpackage >> build without inserting an Obsoletes/Provides pair. So, what may be of >> some limited use while testing builds, is of no use in packages released >> into a public distribution. > I second this opinion. We've had a similar discussion within the > upstream OpenVPN team as well. Most distributions have their own > tracking of the .spec files, with their own set of packaging guidelines > and preferences how things should do. Yes, it is possible to use %if to > get around all that. But the end result in the .spec file is much > harder to read and follow. > > I recommend to let distributions be distributions, and let each > distribution carry their own .spec file - especially targeting their > needs and processes. The benefit of carrying a unified .spec file is > really not worth the efforts in the long run IMO. There is also this policy: https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Canonicity Vít _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
