Fedora Extras, Fedora Core CVS Open!

[Dries Verachtert]

On Friday 17 December 2004 19:11, Michael Favia wrote:

> > 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.

Please note that 'the independent  repositories' are not only busy with 
backwards compatibility for older Fedora Core or Red Hat Linux releases, but 
also with compatibility for other/newer distributions like for example Aurora 
Linux (a Fedora Core for Sparc) and Fedora for Alpha and Yellow Dog Linux and 
RHEL (or clones) and simply getting stuff working on the newest Fedora Core 
itself (for example compile fixes for the newer gcc or amd64). 

And yes indeed.. normally all from the same spec file! I bet you're all 
thinking now that those spec files really must be evil and full of weird 
macros. :-)
Well actually, they're not. I really would like to invite you to have a look 
yourself!

You make it sound as if compatibility is something holy for Dag and other  
independent repositories. That's a bit exagerated i think.  If the spec file 
builds and works fine on older or other distributions, then why won't you use 
that possibility? Instead of only the users of recent Fedora versions, you 
can make a lot of other users happy too with a minimum of effort :-)

For example when i make a spec file, then i test it and build it for Fedora 
Core 3 first. Most of the time, the same spec file builds and works also on 
'not too old' versions like Fedora Core 2 and other quite recent distros like 
Aurora 1.92. If the program looks usefull to me  and only a minimal effort is 
needed to get it to compile & work too on for example Fedora Core 1.. then 
why not? But if it requires more work (like when it needs a recent Gnome or 
KDE) then i won't even think of trying to achieve backwards compatibility.  
Backwards compatibility is nice, but only if it doesn't require a lot of 
work. 

It's not "keeping every program/spec file backwards compatibile with 
everything since RH 7.3" which i think is important, but "having the 
possibility to keep a program/spec file working on other and older distros if 
it's not too much work".

To achieve that goal, we use one spec file for a program, which can contain  
some easy macros, where most of those macros are only used for  
buildrequirements. We can't maintain a spec file for each distro/arch 
combination.. that's too much work.

Please don't get me wrong: the project Fedora Extras is really great for the 
Fedora community, but in my humble opinion the same project can also be great 
for a lot more people with only a bit of work :-)

kind regards,
Dries Verachtert

PS: You can find those spec files at http://svn.rpmforge.net/svn/trunk/rpms/ 
and  http://dag.wieers.com/packages/ and 
http://dries.ulyssis.org/ayo/packages/ and others.