Description of problem: In the same way that cups-libs is a sub-package of cups, with the server part being in the main 'cups' package and the libraries in 'cups-libs', I think avahi needs to package its libraries in a separate avahi-libs sub-package. Version-Release number of selected component (if applicable): avahi-0.6.25-5.fc12.x86_64 How reproducible: 100% Steps to Reproduce: 1.rpm --test -e avahi --allmatches 2>&1| grep cups-1 Actual results: libavahi-client.so.3()(64bit) is needed by (installed) cups-1:1.4.1-10.fc12.x86_64 libavahi-common.so.3()(64bit) is needed by (installed) cups-1:1.4.1-10.fc12.x86_64 Expected results: No output. Additional info: The avahi package should be installed by comps, not by dependencies. In a similar way, cups is installed by comps instead of being a dependency of e.g. gtk2 which uses libcups. Original bug report: bug #513559
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Makes sense to me, but we probably want to target F13 for this now.
*** Bug 542775 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
pinging on this one again - subject came up on an irc discussion and I remembered this bug. I realize it is too late for F13 at this point - but maybe rawhide? thanks
I'd argue that this needs to happen in F13, heck I'd argue this needs to get back ported to F11 and F12 (depending on when support gets dropped for F11). It's just the fact that avahi is going to get turned on for a lot of server installs that aren't expecting it (and arguably a lot of desktop / laptop installs that might not want it as well).
I don't see the point given that it'll be blocked off by default, by the firewall, and that you'd need to explicitely unblock it from the firewall for it to do anything. At that point, you might as well be disabling it running altogether.
(In reply to comment #7) > I don't see the point given that it'll be blocked off by default, by the > firewall, and that you'd need to explicitely unblock it from the firewall for > it to do anything. At that point, you might as well be disabling it running > altogether. Your making the assumption that the firewall is either running at all, running in the default configuration or that an attack at the local system is impossible. There are specific reasons why an end user, in particular servers, don't run firewalls, or run firewalls that are incredibly targeted and specific. Depending on your firewall to protect you against this particular problem means you've already failed. Here's the fundamental problem that started this whole debate, if I as a server administrator am not running avahi, have a machine on the public internet and such suddenly decide to install ImageMagick, a completely unrelated package that should *NOT* involve any new services I am suddenly bringing in avahi and it's starting by default. It's the completely unexpected implication that anything I want that needs ghostscript will mean that I not only suddenly have bloat installed, but that I'm not by default running a service I wasn't expecting.
Done in avahi-0.6.25-7.fc14.