Fedora Extras, Fedora Core CVS Open!

[Cristian Gafton]

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 at redhat.com      --     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