On Fri, Apr 23, 2010 at 10:57:54PM +0200, Nicolas Chauvet wrote:
2010/4/23 Jack Neely <jjneely(a)ncsu.edu>:
> On Fri, Apr 23, 2010 at 05:40:37PM +0200, Nicolas Chauvet wrote:
>> 2010/4/23 Jack Neely <jjneely(a)ncsu.edu>:
>> > Folks,
>> >
>> > The RHEL 6 Beta is out and I'm interested in rpmfusion support for
RHEL
>> > 6. Sounds like EPEL will be branching in a week or two. I'd like to
>> > put some work into making this happen.
>> >
>> > I guess the first step is to get RHEL6 Beta1 on more mirrors so that we
>> > can have easy access to the Yum repos.
>> I would be interested in creating an el-6 branch right now also.
>> But because anything above ffmpeg in F-13 is doomed because of
>>
http://www.videolan.org/security/sa1003.html
>> I would branch some packages from F-13 tree. (and vlc from F-14).
>>
>> That been said most packages should be branched from F-12, so the question is:
>> How much of the current RPM Fusion packages maintainer do want to
>> support their package in EL-6 also ?
>> (so that we can eventually automatically branch packages from F-12)
>>
>> Nicolas (kwizart)
>>
>> ps: that been said, I cannot expect anything in el-? branches before
>> we solve two questions:
>> How to move to our own hosted koji build server infra ?
>> how to deal with kernel module in the EL world (where a stable kABI is
>> the rule).
>>
>
> I've been using the kmod standards as rpmfusion knows and loves with
> RHEL5 since it was released. It works very well there. I don't see
> this one as a blocker.
Which ones are you talking about? kmod1 or kmod2 standard ? And which
one supports kABI if any ?
The point is: I'm not aware rpmfusion ever did kABI the way it's
currently done with Red Hat.
Of course that's not about a blocker, but a decision to be made along
with a team to be in charge to maintain.
Nicolas (kwizart)
I've used both kmodv1 and v2. However neither support the kABI
packaging model.
Being that we have limited resources and we have a model for maintaining
kernel modules that works with Fedora, we should use that same model
with RHEL6 unless there is some incompatibility.
By the way...we are the "team." :-) I just don't think RHEL6 is
different enough to re-engineer our processes for it.
Jack
--
Jack Neely <jjneely(a)ncsu.edu>
Linux Czar, OIT Campus Linux Services
Office of Information Technology, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89