Re: avahi-daemon
Hi,
On Sat, Mar 04, 2006, Philipp A. Hartmann wrote:
> Well, since the gnome meta-package is part of the gnome task, which I
> consider a common default to setup a desktop machine, it get's pulled in
> in an environment where Recommends are installed automatically.
Yup, so the GNOME task pulls it in by default, which means you get the
feature and the open port.
> I think, your proposed solutions do not cover this issue at all. Users,
> who know what they want and what they are doing, do not run into this
> problem, since they can manually deselect avahi-daemon. We are indeed
> talking about regular users. In another mail, you agreed, the maybe only
> 10% of them want to share music. So, why give another open port to the
> other 80% (assuming, that 10% of the users know what they are
> doing ;o)).
Ah you're correct, let's make it a Recommends: for the 10% of people
wanting to share music, and a Suggests: for the 80% of people having no
clue and which will never share music in the life of their system.
> But still it's only a Recommends. Therefore, rhythmbox needs to handle
> the absence og avahi-daemon gracefully, since you cannot rely on it's
> installation. For sake of plug-and-play and comfort, this might be even
> done in some kind of GUI message, which tells the user what to do, if
> he/she wants to access a feature, that requires the daemon's presence.
It's completely correct to request the proper behavior of RB when the
recommends isn't there. I could be very silly, and argue the other way
around with something like "the current RB code doesn't properly permit
using RB without avahi-daemon intalled", and make that a Depend, but
since I knew it was causing pain to people wanting a system without
avahi but with gnome, and since RB was fixed not to crash when avahi
wasn't there, I could downgrade that to Recommends.
In other words, RB could be enhanced to work better when the
Recommends isn't installed indeed. I don't consider a popup in the
application to request installation of packages sensible at all.
> If you agree on this, there is no reason, to lower the dependency to a
> Suggests and everybody would be happy. If you still think, that a
> feature, that is present by default but might be used only by a limited
> number of users overweighs the possible security implications of another
> open port, I think we really cannot come to a consensus in this point.
It's exactly the way you put, it, we can not come close to a consensus
by comparing apples to oranges, security and usability.
I must add people on this list are obviously biased towards security.
Cheers,
--
Loïc Minier <lool@dooz.org>
Current Earth status: NOT DESTROYED
Reply to: