On Fri, 26 Nov 2010, Ingvar Hagelund wrote:
* Dag Wieers
RPMforge is a third-party repository for RHEL, CentOS and Scientific
Linux. It provides add-on RPM packages that increase functionality and
productivity for both Server and Desktop based environments. (...)
= RPMforge now consists of more than one repository:
+ rpmforge - packages that _do not_ replace base packages
(eg. nagios, wine, vlc, xine, mpg123, ...)
+ rpmforge-extras - newer packages that _do_ replace base packages
(eg. lftp, rsync, subversion, ...)
+ rpmforge-testing - alternative test packages
(eg. wine-1.3.x, ...)
+ rpmforge-buildtools - packages required for building RPMforge pkgs
(eg. bison, make, rpm-macros-rpmforge, ...)
For convenience, packages belonging to one of the above repositories
are tagged respectively with rf, rfx, rft and rfb distribution tags.
First: This is GREAT news. Thank you so much.
Second: This may be a FAQ, but anyway; will there be much overlap
between rpmforge and epel, or will you try to avoid parallell work by
skip packages that exists in epel? (In short: Is it a goal to make
rpmforge and epel more compatible?)
The reason why EPEL is not compatible with RPMforge dates back to the days
when Fedora was started. We already were packaging for Red Hat and RHEL,
and were interested in Fedora too. Fedora Extras did not exist in those
days.
It was clear that Fedora was not interested in RHEL packages at that time
and since that was our main focus anyway, collaboration was no option (you
can find those discussions on the Fedora mailinglist archives). It was
rather painful.
Anyway, a few years ago some people in the Fedora community became
interested in RHEL packages, and so they started from their own collection
of packages, which by then were not compatible with what we already had.
Hence the current situation.
I think both we as well as EPEL are interested in becoming compatible, but
unfortunately that's something that is very hard to achieve, not only
because it requires a lot of communication (which is seen as an impediment
to someone's work) but also that nobody wants to carry the effort.
I have some ideas on how we could improve the situation, and which could
eventually lead to compatibility with EPEL. And in fact made some
modifications to my buildsystem to test whether this would be possible,
but because there are some more important issues to address I don't think
it is a good time to introduce that now.
--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, i...@dagit.net, http://dagit.net/
[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest
