I think that the problem is clear. Red Hat/Fedora Core have different<snip>
goals than independent repositories. The goal of Fedora Core is to have
a stable set of packages for a release which then don't evolve much - we
only fix bugs with security impact or other serious bugs.
That's much different from independent repositories such as Dag's because they have the goal to deliver packages of new versions of various software to as many distributions as possible. For this it's much better to have one spec file with macros.
So the question is, will Fedora Extras be more like independent repository or more like the Fedora Core. Or it could depend on package.
This is the first response to address the real issue in my opinion. If fedora extras is meant to be on par with fedora and maintain a forward looking policy (eg new releases for current FC and security fixes only for past FC) then the choice seems fairly easy.
The real question is: "Is the independent packaging community willing to follow this mantra of 'moving forward' and thus abandoning backwards compatibility without maintaining separate spec files"?
If not is the cost of regressions/complexity in the spec files (that they want to use) greater than the benefit of having those individuals on board?
Perhaps the real issue we need to be asking is while it is very nice (i repeat: very nice and greatly appreciated) to be able to install new versions of various software on my FC1 boxes, how inline with the goal of the fedora project is that? I would argue that it doesnt really have a place, at least not in fedora extras. But, we need the independent package managers onboard and to do so we either need to convince them of the benefits of a forward looking approach to this distro or we need to allow at least some the complexities they bring with the skills they honed in more stable and longer life cycle distros.
I personally believe that the fedora extras should compliment Fedora Core by adopting the same style of release pattern on a wider array of packages that, for various reasons arent included in Core. The other goals such as backwards compatibility seem to have a place in a Fedora Legacy project.
<Important Part> Maybe maintaining 2 spec file sets is the best solution:
1 for Fedora core that is simple an focuses only on the current release
1 for Fedora Legacy that includes macros and attempts to bring extended support to the fedora core distribution
That way the barrier to entry for innovation remains low and individuals dedicated to maintaining historical perspective can do so efficiently. I confess ignorance on the details of such an implementation but it seems a likely solution for everyone involved from my point of view.
</Important Part>
happy holidays, mf
-- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com
