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