On Sun, 2008-05-11 at 13:26 -0300, Paulo Cavalcanti wrote: > > Because Fedora x (some x) and ELx (any x) don't > include it, but Axel supports them.
EL still requires lirc, but all supported Fedora releases have lirc driver in-kernel and lirc userspace provided. > > > 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). F7, F8 and F9 all have lirc drivers in their kernels. There may be a few modules not built that could still stand to be built, and that could be done either in-kernel or in a kmdl. > Which modules are missing? > > In my experience, it is much more problematic > to maintain a partial package than the whole thing. Why? The spec file contains a static list of which modules to build. > You end up having to compile everything > to throw away the common part. Not true. You only have to compile the modules you want to build. > 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. Nb: if/when I find time, I *might* start tracking the dvb mercurial tip (or at least reasonably stable snapshots thereof) in the Fedora kernels. > Furthermore, I do not like having part of a package compiled > in a building system and part on another. Is to ask for > problems... lirc is pretty well separated between userspace and kernel space. I've been building them separately for quite some time without an issue. If there ever *is* a problem, I maintain the lirc kernel patches in Fedora and am a co-maintainer on the lirc userspace packages in Fedora. Yell if something actually breaks, and I'll fix it. > 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. Huh? No it won't. I've been building my own mythtv packages against the lirc-devel in Fedora for AGES and lirc support works just fine, thank you. You do NOT need the static lib for anything in mythtv. If the ATrpms mythtv build requires the static lib (I'd be really surprised if it actually did), then its broken. > 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? I'm still completely and totally convinced nobody needs a 2nd version either. -- Jarod Wilson [EMAIL PROTECTED] _______________________________________________ atrpms-devel mailing list [email protected] http://lists.atrpms.net/mailman/listinfo/atrpms-devel
