Hi, On Sat, 2006-03-04 at 10:26 +0100, Loïc Minier wrote: > Concerning your dependencies remarks, I think I've answered to them > enough already: this is a Recommends, nothing pulls in rhythmbox from > a standard install up to a gnome-desktop-environment install, I > proposed dependencies workarounds for most use cases (have a conflict > from security packages, use your own meta-package...). 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. 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)). > > If you feel there's a technical problem with the technical choices of a > package or meta-package, bring it as a bug report, linking to this > discussion, and if you don't get maintainer's agreement, please bring > it to a technical committee. It's really here to help take technical > decision where consensus can not be reached. I have a technical question here. First of all, I think, that avahi-daemon listening on all interfaces by default, is what we want. It's the only reasonable setup for a multi-cast discovery daemon. A Debconf question about this is not even necessary here, IMHO. OTOH, the majority of Rhythmbox users might not want to share music, but install rhythmbox in an environment, where Recommends are pulled in automatically. Ok, we discussed that. 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. 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. My two cents. Philipp
Attachment:
signature.asc
Description: This is a digitally signed message part