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(a)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