RPM Fusion for EL/EPEL 5

[Thorsten Leemhuis]

On 16.08.2008 01:41, Nikolay Ulyanitsky wrote:
> Thorsten Leemhuis :
>> So if you want to maintain all or some of you packages for EL drop me 
>> a line please. Then I'll create branches for them sooner or later and 
>> help with the initial build round just like I do for Fedora now.
> [...]

reply a bit out of order ;-)

> I want to help to maintain some packages for EL branch in RPMFusion that
> don't have owners yet.

Welcome Nikolay! It's great to see people showing interest in the EL 
stuff that RPM Fusion plans. I suppose we can need a few helping hands 
there, as some of the RPM Fusion packagers likely have no interest in EL 
stuff.

 > [...]
> We rebuilded several packages from Livna 9 / Fedora 9 repositories with
> small changes and added own packages.
> 
> * Packages list
> http://www.redhat-club.org/Repository/Packages 
> * SRPM repository
> http://repo.redhat-club.org/redhat/5/SRPMS/
> * SVN (only spec files, patches and spec.diff (diff between original
> spec and modified))
> http://svn.repo.redhat-club.org/

Thx for the pointers. If there are patches in you packages that might be 
of general interest then consider to send them to the RPM Fusion package 
owners; you can find them in these files

http://cvs.rpmfusion.org/viewvc/free/owners/owners.list?view=markup
http://cvs.rpmfusion.org/viewvc/free/owners/owners.epel.list?view=markup
http://cvs.rpmfusion.org/viewvc/nonfree/owners/owners.list?view=markup
http://cvs.rpmfusion.org/viewvc/nonfree/owners/owners.epel.list?view=markup

At the same time it might be wise for the RPM Fusion packagers to look 
for changes in SVN from the "Red Hat Club Repository" (see above for the 
URL). That might makes things easier and avoid pitfalls/bugs -- 
especially when you try to build your packages for EL.

Note that lkundrak recently published a repo which holds some of the 
Livna packages rebuild for EL as well; see

http://elvn.getrpm.net/
http://elvn.getrpm.net/svn/packages/
http://elvn.getrpm.net/rpm/el5/

for details and patches.

> kmod's is builded by RHEL technology: is not necessary to rebuild
> them for every kernel update or build akmod's or dkms packages
> because RHEL kernels have stable KABI (kmod builded for RHEL 5.0 will
> work on CentOS 5.2 and vise versa).

I hope we can do the same for RPM Fusion -- but I have not looked into 
that yet.

In fact we didn't even agree on what kernel module packaging standard to 
use for RPM Fusion at all -- but your comment imho is yet another reason 
to go the kmod route, as this afaics provides all that we need:

- pre compiled kmods (Fedora)
- pre compiled kmods that are not kernel specific (EL)
- dynamically builds kmods using akmods (mainly Fedora, but might be of 
interest for some EL users as well)

Cu
knurd