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)
Michael A. Peters wrote:
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.
Sure. I can co-maintain the packages.
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)
Alpine is already in EPEL 5 testing repository. It will be moved to EPEL 5 within a couple of days.
Rahul
On Feb 1, 2008 5:23 AM, Rahul Sundaram wrote:
Michael A. Peters wrote:
also unrelated - someone really should branch and maintain alpine. EL is
Alpine is already in EPEL 5 testing repository. It will be moved to EPEL 5 within a couple of days.
Thanks Rahul. I'd also like mention that it was always my intention to get alpine in el4 and el5, but I was holding off until 1.0 for just the reasons you like CentOS5, Micheal: fewer updates right at first and stability. I've also mentioned a couple of times on mailing lists that the Fedora alpine RPMs work fine on EL5.
epel-devel@lists.fedoraproject.org