[ATrpms-devel] The state of lirc...
Paulo Cavalcanti
promac at gmail.com
Sun May 11 18:26:18 CEST 2008
On Sat, May 10, 2008 at 7:21 AM, Paulo Cavalcanti <promac at gmail.com> wrote:
>
>
> On Sat, May 10, 2008 at 12:00 AM, David Rees <drees76 at gmail.com> wrote:
>
>> On Fri, May 9, 2008 at 6:12 PM, John Robinson
>> <john.robinson at anonymous.org.uk> wrote:
>> > On 09/05/2008 16:56, Jarod Wilson wrote:
>> >> Remind me again... Why does atrpms continue to package lirc?
>> >
>> > Because Fedora x (some x) and ELx (any x) don't include it, but Axel
>> > supports them.
>>
>> Jarod's point was to go ahead and build them for the distros that
>> don't have the proper support upstream, but for those that do, drop it
>> or only build the parts that are needed (like the kmdls possibly in
>> F8's case).
>>
>
> Which modules are missing?
>
> In my experience, it is much more problematic
> to maintain a partial package than the whole thing. You end up having to
> compile everything
> to throw away the common part. That is exactly what happens to xine, and
> its free/non-free part (its nuts in my opinion, but solves a license
> problem).
>
> The video4linux package in ATrpms exists just to cope with the rapid
> development upstream, and
> the big delay to see the new code in a new kernel. Furthermore, I do not
> like having part of a package compiled in a building system and part on
> another. Is to ask for problems...
>
> Maybe we could start using the same nomenclature for lirc and its
> components? This way, those who do not need anything special could just use
> the RedHat package and nothing else, or switch from one version to the other
> very easily.
>
>
A final remark. The way myth package is now,
it requires the lirc static library (liblirc_client.a),
during compilation. This lib is not present in
Jarod's (devel) package.
Since RH banned static libs sometime ago,
this one will be difficult to accommodate.
I my case I had to recompile Jarod's packages to
be able to use and develop with them in Atrpms.
Basically, I am building the missing static library
and providing lirc-lib-devel in lirc-devel.
But no one needs a third version of lirc packages, right?
--
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.atrpms.net/pipermail/atrpms-devel/attachments/20080511/e6f2d428/attachment.html
More information about the atrpms-devel
mailing list