Howdy. I was a fedora contributor, I orphaned all my packages there
because I was unable to keep up with rawhide and new versions of Fedora,
and thus was not able to properly maintain packages.
I no longer run Fedora (er, I did install F8 yesterday, but I plan to
not use it very much) but instead run CentOS as CentOS is more to my
taste with respect to longevity of the distro, and the fact that it
still runs nicely on my low memory Thinkpad T20 (which really choked
pretty bad on F8 when FC6 went EOL). I also like how stable CentOS was
when installed, Fedora is always a bit quacky for the first few months
after a release (quacky is a technical term, no?)
But I really like the quality packaging Fedora aspires to produce, and I
like the variety of packages Fedora has to offer.
Some glaring omissions from EPEL are the "lighter" office solutions -
notably AbiWord and Gnumeric and Dia.
Good news is the F8 src.rpm's build fairly easily.
The dependencies for AbiWord and AbiWord itself "just build" without
modification. Dia "just builds" now, no missing dependencies. Gnumeric -
one dependency needs tweak - that's libgda.
libgda has two issues:
1) rhel/centos do not have the sqlite version needed to meet F8 src.rpm
BuildRequires. That's easy, just comment out the BuildRequires - it has
its own sqlite in the source that it will use when configure doesn't
find sqlite new enough.
2) there's a bug in the makefiles that causes a man page not to be
installed. lazy fix is to manually install the man page in spec file,
proper fix would be to find out why it fails and patch it.
Gnumeric itself also needs a minor tweak - the findlang macro misses one
file that it finds in F8.
Anyway - here's the lowdown of what EPEL needs for these gnome office
apps (I guess dia technically isn't gnome office, but ...)
link-grammar
aiksaurus
hspell
enchant:hspell
ots
gtkmathview
abiword:link-grammar aiksaurus enchant ots gtkmathview
mdbtools
mod:libgda:mdbtools
libgnomedb:libgda
mod:gnumeric:libgnomedb
dia
mod: means I had to mod the spec file to get it to mock build in CentOS 5.
Packkages after a packagename: means they are BuildRequires that have to
be built first.
That's a dozen packages that could fairly easily be branched into EPEL
that would definitely be useful to many people. I've verified they build
and work in i386 and x86_64 (though my x86_64 machine is new, less than
a week old as I type)
I'm willing to help maintain them in EPEL but I don't want to be sole
maintainer of a dozen packages, and I would prefer to have a
co-maintainer. There's a real good possibility I won't install
RHEL/CentOS 6 when it ships - I use to like running latest greatest but
now Linux is good enough that I prefer not to mess with what works. So I
don't want to be in a situation where I take some on and then end up
having to orphan because I'm not running relevent versions of the OS.
But any help I can provide, I'm more than willing to. I even would
consider maintaining a few branches solo if there were other people
maintaining some of the others.
-=-
also unrelated - someone really should branch and maintain alpine. EL is
often used on servers that people often access via remote shell, and
pine was "the standard" mail client for those scenarios. I bet alpine
will be in RHEL 6 anyway, but it should be EPEL branched for 5 (it
builds and works just fine i386/x86_64)