[elrepo-devel] Contributions

[Nelson Marques]

Phil,

There's actually one issue around, I'll try to be brief and explain
it... The kmod spec file can be improved, but that required to add an
extra patch, I do have it implemented that way on my $dayjob.

Since on Enterprise Linux we have kernel ABI assured by Red Hat, we
can use the weak-updates to keep the module working after a kernel
update without having the need of rebuilding it (ABI should remain
compatibable, so far it has). For this the kernel module needs to be
installed on extras/dahdi, and the default makefile installs it on
dahdi. So we have actually two options:

 1) move the kernel modules on the spec to a new location (which means
hacking the default kmodtool from redhat);
 2) patch the makefile to read the environment var used on the spec
(which was what I did), so you don't change the kmodtool and you have
your modules always working after a kernel update through
weak-updates.

Now this is nice because you don't need to update DAHDI after an
official kernel update, and you don't need compilers on production
servers to rebuild modules (which terminates what some consider a
security issue (having the compiler on a production server)).

Which reminds me... I have this on my work svn already done, so if you
wait till monday I can send a new spec for the kmod and the patch
(yes, I can share it).

Sorry, I jsut remembered about that.

NM




2012/3/15 Phil Perry <phil at elrepo.org>:
> On 15/03/12 19:05, Nelson Marques wrote:
>> Hi,
>>
>> My apologies for taking so long to reply, I've been involved on a
>> 'royal mess' and my time was pretty much to fix a lot of ongoing stuff
>> in several projects that I'm related.
>>
>> In attach I have two spec files for DAHDI, one for the kmod and
>> another for the dahdi-tools (userspace). This specs use the
>> traditional 'kmodtool' provided by Red Hat and clones. I've disabled
>> the debuginfo package on the spec, which you might want to re-enable.
>>
>> My thing is, anyone wants to test out builds, raise any questions
>> regarding the spec, or discuss before we can put on this on testing?
>> (This have been tested internally mainly with the dummy device).
>>
>> This packages also include the udev traditional stuff to create the
>> devices with the right asterisk permissions to be used.
>>
>> Please provide some feedback, and let me know of the normal steps to
>> package and maintain this package on elrepo. For the initial steps and
>> phase I trully would appreciate if someone could mentor me around :)
>>
>> PS: I can also provide the SRPMs if required.
>>
>> NM
>>
>
>
> Hi Nelson,
>
> I'm happy to build your packages for elrepo so folks can have something
> to test (although I'm up to my eyes so it's going to take a little time
> - if anyone else wants to jump in in the meantime, feel free). That
> should at least get the ball rolling.
>
> Then if you are interested in maintaining them going forward, I am more
> than happy to offer whatever help you require. The hardest part is
> always creating the initial package :-)
>
> Regards,
>
> Phil
>
>
> _______________________________________________
> elrepo-devel mailing list
> elrepo-devel at lists.elrepo.org
> http://lists.elrepo.org/mailman/listinfo/elrepo-devel



-- 
Nelson Marques
// I've stopped trying to understand sandwiches with a third piece of
bread in the middle...