On Sun, May 11, 2008 at 9:58 PM, Jarod Wilson <[EMAIL PROTECTED]> wrote:
> 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. That would be very nice. > > > > 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. Then you have my vote. The success of mythtv in Fedora/RHEL is because, in great part, the work of Axel and yours. > > > > > 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 just tried to rebuild Axel's .src.rpm (0.21-187) for FC6. Without the static library it does not link. I really tried, and it does not go .... One has to have the .a bit. Perhaps it is just a questions of changing the myth spec file. I do not know. Statically linking lirc to mythtv seems to be more appropriate, but new myth versions come so fast, that it really does not make any difference after all. Your packages work just fine for me with the two changes I told you, static lib and lirc-lib-devel. I also prefer your nomenclature, such as /etc/sysconfig/lirc (not lircd). Since you are the lirc maintainer in Fedora, my vote is to use your packages for Fedora. Unfortunately, however, Axel will have some extra work to do ... -- Paulo Roma Cavalcanti LCG - UFRJ
_______________________________________________ atrpms-devel mailing list [email protected] http://lists.atrpms.net/mailman/listinfo/atrpms-devel
