Fedora Extras, Fedora Core CVS Open!
Dag Wieers
dag at wieers.com
Fri Dec 17 06:30:56 UTC 2004
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]
More information about the devel
mailing list