On 03/06/2015 01:52 PM, Jonas Smedegaard wrote: > Hi Thomas, > > Quoting Thomas Goirand (2015-03-06 12:05:38) >> On 02/27/2015 11:45 AM, Jonas Smedegaard wrote: >>> libminiupnpc10 recommends minissdpd. As a consequence, any package >>> which links against the library pulls in the daemon. >>> >>> Please lower to only suggest, so that Bitcoin, Transmission and other >>> tools linking against this library can each decide on their own how >>> strongly they consider their relation to be. > >> I do not agree with you. The minissdpd really is a useful tool, which >> speeds up discovery in the LAN, and I think it's a good idea to have >> it as a recommends. Tools like Bitcoin, Transmission and others will >> work better regarding to UPnP if minissdpd is running. You can read >> the description of minissdpd if you don't know why yet. >> >> So, I believe having minissdpd as a recommends is exactly what should >> be done here, and I don't really think it's a good idea to revert >> this. If you do, please explicitly say why, as here you haven't >> explained why running minissdpd is not what we recommend. > > Currently the library dictates for all of its consumers how important > the daemon shall be for them. > > I argue that each consumer shall be allowed to declare on their own how > important the daemon is for them. > > You now look at concrete consumers, and argue that all of the ones you > look at make sense to recommend the daemon - but that does not change my > underlying point that each consumer should be allowed to decide that > rather than have that dictated by the library. > > It is wrong of a library to dictate how important itself and its > surrunding tools are for its consumers. > > Example: Imagine if Bitcoin package maintainers decide that uPNP is nice > but may be considered a security risk for some users, and therefore > should be treated as an *optional* feature for that package. Currently > you impose a recommendation that they can only avoid by not linking at > all or by rewriting code to be a plugin which can then not be installed > at all. You make flexibility harder, which is bad for Debian. > > Does that make sense? > > - Jonas
Jonas, I've asked you why you think the daemon isn't useful. Instead of replying to that, you're discussing about the fact the control of the Recommends should be on each and every consumers. I may agree to your opinion to some degree. However, there's a few points that I believe you're missing. - The minissdpd daemon is very lightweight and doesn't consume much resources on one's computer, so running it is kind of "free" these days. - Having minissdpd running is completely orthogonal to supporting UPnP on your LAN. You may have UPnP setup in a LAN, but no minissdpd on your laptop/workstation, and UPnP would still continue to work (but discovery will be slower). On the opposite way, if UPnP is not setup in your LAN, running minissdpd doesn't pose any problem. The only thing that minissdpd does is running a cache, so that libminiupnpc acquires the knowledge about the existence (or absence) of a UPnP router faster. So it provides benefits in all cases. Just read about the long description of minissdpd... So your point about a given package maintainer thinking about a security risk for UPnP doesn't make much sense. Having the "Recommends: minissdpd" bits on every package which is using libminiupnpc is IMO not a good idea, because some package maintainer may not even think/know about it, and it is preferable to have this relation on a single package. As you know, "Recommends:" is also flexible enough, so that users who know what they do will remove the package if they don't want it, though it will pull the daemon for the majority cases where users don't even know what minissdpd does, and that's really the behavior I wanted. Now, if we still don't agree, do you think it'd be a good idea ask for someone else view? I'd be very happy to have a neutral 3rd party to examine the situation, and voice an opinion. Do you think it'd be a good idea to ask the technical committee about their view on this? We don't have to ask them to actually decide with a formal vote, but just to voicing an opinion by the members who have enough time to do so would be nice. Your thoughts? Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
