Fedora Extras, Fedora Core CVS Open!

[Dag Wieers]

On Fri, 17 Dec 2004, Cristian Gafton wrote:

> On Thu, 16 Dec 2004, Michael Tiemann wrote:
> 
> > > Only fork SPEC files when the complexity of maintaining them becomes
> > > harder than the complexity of keeping things synchronised.
> > > 
> > > My estimate is that for 70% of the cases 1 SPEC file can rule them all.
> > 
> > That would be _extremely_ cool.
> 
> There is more to maintaining packages that how cool you can make your
> specfiles... We can play the coolness game, we can even have some sort of
> competition for the coolest, wicked packaging job ever. But that won't do a
> bit to help maintain those packages over the long haul, or by a team of people
> with different coding styles and appetites for coolness.

http://dag.wieers.com/packages/xine-lib/xine-lib.spec

Now, imagine the distribution-specific stuff is in a macros file per 
distribution and consider the fact that if you don't do something 
likes this, you need either 8 different SPEC files or manage which SPEC 
files did build on what distribution and reduce it to 5.

Again, if Fedora Extras goal is to not care about more than 2 releases the 
discussion is over.


> When you ask the question of "how do you improve maintainability", this turns,
> unfortunately, into a game of lowest common denominator. The "_extremely_
> cool" hack from somebody looks like a retarded spewage to somebody else.
> That's the advantage of a one man repository - there is one person deciding
> what's cool and what's not. When a team of folks from across all continents
> are involved, avoiding being cute works much better.

It's not a hack. If it was part of RPM's standard (the %dist macro and 
infrastructure) you'd be using it. And if you make a clean policy around 
it, it would be simple, maintainable and efficient if used wisely.

Forking for a few BuildRequirements or forking because some distribution 
lacks something is adding double overhead for a file that's 99% the same.

It will cause people not to do updates for less important items just 
because they may have to do the same thing 2 or 3 times.

PS If you don't like macros, I'm sure you can come up with another 
solution that doesn't add more overhead and doesn't require needless 
forking. I'm not in a position to influence RPM development.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]