Re: [users] Re: RPMforge Fedora Core 4 repositories
Dag Wieers <[email protected]>
| Newsgroups | gmane.linux.freshrpms.user |
|---|---|
| Organization | 3TI Web Hosting Services |
| Message-ID | <[email protected]> |
On Wed, 22 Jun 2005, Justin Conover wrote: > On 6/11/05, Dag Wieers <[email protected]> wrote: > > > Regarding Fedora Extras compatibility, FE has been duplication some of the > > packages RPMforge provided and with every duplicated package the > > probability of incompatibilities grows, this will take a few weeks to > > settle and fix. If you plan to help out in this area, send us your > > feedback to: [email protected] > > Will you be removing the duplicate packages our how do you see going > about this? I'm just wondering since extra's in now part of Fedora. > I can see the stuff that goes on with Livna and the only package I use > from them is the Nvidia.rpm because it is a pretty clean way of using > it. Again, RPMforge is not only covering Fedora. So we will stick with our packages and depending on the people volunteering to help out we will track changes with both Fedora Extras and other distributions. There is a difference between what RPMforge is doing and what Fedora Extras is doing in keeping SPEC files backwards compatible. Mostly by consistency and simplicity. With Fedora Extras the backwards compatibility is thrown away with every new fork. And I'm not considering dropping RHEL3 or CentOS3 since keeping backwards compatibility is no real overhead, it just requires discipline. My hope is that we can build a community around pieces of software cross-distribution. Since patches, bug-reports, development and users are usually not distribution specific. I like the way Ubuntu is moving, creating software that tracks progress cross-distribution. I've been very interested myself in developing a piece of software that can track changes, bugreports and patches by other packagers to build bridges with other distributions. We're all in the same sh*t :) And there's no good reason to sit on distribution-specific islands anyway, that's what's driving SLES away from RHEL away from Ubuntu. Everything that is not covered by the developers is akin to drift away The clamav package is a good example, I have been begging for a few decisions from the developers to keep things consistent, but they don't care, they leave too much to the packagers, which is a bad thing. End-result is that every clamav packager is doing it their way. Developers need to dictate more, freedom is not always a good thing. Maybe that a few tools can make packagers communicate and we can get rid of some duplication. I'll stop my 'tirade' here :) -- dag wieers, [email protected], http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]