On Fri, 17 Dec 2004, Cristian Gafton wrote:
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.
We don't do complex macro things and I would prefer simplicity over macros
anytime. Complexity is not inherent to macros, sure you can abuse it. I
have seen ugly unmaintanable SPEC files myself that did not include
macros. Common sense and good policies will be required, especially if you
allow anyone and her cat to join. :)
... An yet having worked on a good number of Linux releases since way
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
Then I'm sure you have met the wrong packagers. Reading this makes me
wonder whether there was any thought about maintainability at all.
Bad examples don't make good decisions.
> Only fork SPEC files when the complexity of maintaining them
> 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.
Sure, I'm oposed to complexity as much as you. But having to keep 3 SPEC
files in sync for a simple change can result in problems as well.
A simple example, FC1 does not have alsa, EL3 does not have alsa, fribidi,
theora, like RH9 and RH8. RH7 misses gnomevfs as well. You'd need 7
different SPEC files, while only a few BuildRequires differ. The overhead
is immense. Of course if you look at Fedora's limited view, you only have
FC3 and FC2 to consider.
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.
Either you don't need the older SPEC file, or you still have to keep it
updated. If you don't need it anymore, branch it, fork it, I don't care.
If you have to keep both in sync, you'll have to test both anyway.
You're right about devel, but why worry if it still builds on older
releases if your premise is to not release a newer package for
older releases anyway ? Either you care about releasing it for older
distributions or you don't. If you don't, you're just developing and not
releasing. As soon as you release, you _have_ to test, no matter if you
have 3 SPEC files or one.
-- dag wieers, dag(a)wieers.com, http://dag.wieers.com/
[all I want is a warm bed and a kind word and unlimited power]