I think that the problem is clear. Red Hat/Fedora Core have
different
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.
<snip>
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