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