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. Once the RPM build tools and packaging guidelines is unified across all RPM based distributions you will find it reasonable to unify the .spec files. -- kind regards, David Sommerseth _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
