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 <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
