On Fri, 17 Dec 2004, Dag Wieers wrote:
Fedora Extras has to decide whether it will allow those extra macros to make it easier to manage SPEC files or if they fork for each new Fedora release. There are a few drawbacks, but imnsho there are more advantages. (less maintenance required, more communities/resources involved, RHEL users don't have to fork Fedora stuff and vice versa, ...)
I can't speak for what is gonna happen to the Fedora Extras in this regard (although I can certainly recommend things :-), but having a single spec file that is capable of building on every possible combination of libraries and releases and compilers and whatnot has always been a great source of pride for whoever achieves that feat. I have done my share of those and it feels great, like the world is at your fingertips and you can rule it all because your single-specfile package builds everywhere, anywhere.
... An yet having worked on a good number of Linux releases since way back, those packages and spec files always end up being the biggest pain in the back. Probably not for as long as the author maintains interest in them and continues to maintain them, but when it comes the time to hand them over to somebody else, the struggle begins. They usually end up being chockfull of hacks for various corner scenarios that a new maintainer has never seen/imagined, they perform extra steps just to get the things "in sync" across all supported releases, etc. All that is knowledge intimate to the author of the super specfile, and it is completely foreign to a new maintainer.
This is why we use the structure that we use (fork for every release) for the Fedora Core and the Fedora Extras. As you can see from the CVS trees that are available, it allows somebody to play the game of a single spec file, if he/she so wishes; but it does not force it on everybody. This allowed us to clean up a good chunk of the macro infestation from the various spec files, improving readability and reducing the number of unintentional mistakes.
Only fork SPEC files when the complexity of maintaining them becomes harder than the complexity of keeping things synchronised.
I would say the opposite is true as well: only maintain a complex spec file if the work required to maintain 3 simpler ones is overwhelming. That is because usually, after a release, 90% of the packages are rarely touched again for that release. And having the freedom of changing a spec file in the devel tree without worrying whether it will continue to build on an older release if you ever have to do a security errata speeds up the development - and that is because the older release has its own spec file that it is known to work as of the time that older release shipped.
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@xxxxxxxxxx -- Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
-- Kenneth Brown, President, Alexis de Tocqueville Institution