Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=487665 Bill Nottingham <notting@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |harald@xxxxxxxxxx --- Comment #9 from Bill Nottingham <notting@xxxxxxxxxx> 2009-03-03 20:30:32 EDT --- (In reply to comment #7) > Spec URL: http://plautrba.fedorapeople.org/soud/soud.spec > SRPM URL: http://plautrba.fedorapeople.org/soud/soud-0.1.3-1.fc10.src.rpm > > 2) Daemon was part of development process and it is now optional. > > Now it is based on udev rules created by soud-save-to-udev.pl from config file. OK, but then I really don't see what purpose this serves at all. All it does is create an obfuscation/abstraction layer between udev rules and its own configuration. Instead of having the user write: ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/sbin/initctl emit bluetooth-start" (which works on any distro), you have them write, somewhere else: [bluetooth_start] filter=SUBSYSTEM=bluetooth ACTION=add action=/sbin/initctl emit bluetooth-start which will only work on Fedora for now. There's no actual value added in the process - it's just a translation layer. And if you're packaging this config, and immediately post-processing it into rules files in %post ... just package the rules files directly and skip the processing. I don't see how soud-watch.pl gives you anything you don't already have with 'udevadm monitor', and if we need more infrastructure there, we should get it added upstream. > 3) bluetooth event.d script checks hw after runlevel changed. if there is no > hw, calls stop on service, same situation if hw is removed. However, given the normal way things work, as this is written now: No hardware: 1) runlevel service starts bluetooth daemon 2) after runlevel, event is kicked off, checks hardware, then stops service Has bluetooth hardware: 1) get udev event, trigger off upstart event 2) since upstart event is running before we enter a runlevel, we won't start the service 3) normal runlevel service will start bluetooth daemon 4) after runlevel, event is kicked off, checks hardware, then exits So, for both the 'normal' boot cases, it adds code and complication to the boot process, without much benefit. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review