Fedora Extras, Fedora Core CVS Open!

[Dag Wieers]

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 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.

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 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. 

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 at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]