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.
