(IMHO this dicussion is reaching to a point in which it should move to d-devel instead, but I'll keep it here) On Thu, Mar 02, 2006 at 09:06:27PM +0100, Loïc Minier wrote: > On Thu, Feb 23, 2006, Javier Fernández-Sanguino Peña wrote: > > IMHO the problem here is having a music program (as rhythmbox) Recommends: > > avahi-daemon, when IMHO it should be Suggests: . The functionality > > provided by avahi-daemon (a network service for sharing music) is not something > > I would say that all rhythmbox users require (based on rhythmbox' description, which > > looks like a music library organization tool for me). However, it will get it > > installed per default by users using 'aptitude' (not 'apt') which is the > > recommended tool these days. > > It would be overly complicated to handle the case of a Suggests instead > of a Recommends correctly: even if the code was updated to handle both Overly complicated? You are overestimating it. It's as simple with a Suggests: as with a Recommends: (people still use 'apt-get' which does not pull in Recommends: automatically). The software cannot rely on it being installed so it should check if the thing it needs is there, if it's not then it asks the user to install it. This can be an error in STDERR (as it is now, I believe) but, more elegantly, could be a window message instructing users what to do and what they gain (and lose) if they do (or don't). It's not that complicated. > cases at run time, and would hide the relevant options when these are > not available, the documentation would still point at unavailable > features. So? The whole point of documentation is to tell people how to do stuff. Rhythmbox' section on "Share music" should start with "You need to have XXXX installed for this feature to work". That's it. As simple as that. > And the popup mixing application level information with package level > information would also be awful: "You should install package foo to get > this functionality". That's been done for ages. Let me bring you a new use case for your consideration (recent in my mind) and related to Suggests/Recommends and enhanced program functionality of another (buggy) program which is music related. First, I would like you to take a look at the ITU's statistics (available at http://www.itu.int/ITU-D/ict/statistics/), you can see there that the average number of PCs per *100* habitants for European countries (in the year 2004) is 28.48 [1] Based on that, you could assume that having more than one computer per household is not all that common. So, I *believe* that your average computer home user is typically going to extract music from CDs (to listen in their computer or on other devices, like MP3 players) more, on average, than sharing with neighbour PCs. Now, take a look at Grip (install it), it's an application to extract audio data from CDs. Grip is useless unless you install additional encoders. If you don't have them (and there are in it's Suggests: or Depends:) then the software should instruct you to go and install them. Grip fails to do so properly, and people bug it often. There's no MP3 encoder in the Debian archive, what should Grip do then? a) suggest: or recommend: inexistant packages [2] b) download and install an MP3 encoder on installation from somewhere lease c) subrepticiously package an mp3 encoder in the Debian package and bypass the FTP masters d) fail to work, and tell user that he cannot find an encoding program e) document the fact that there are no MP3 encoders in Debian and that you have to fetch them somewhere else IMHO, it should do d) and e) not try to be smarter than the user and do a), b) or c) just for the sake of "plug and play". It fails to do so properly (there is no documentation regarding the lack of MP3 encoders in Debian) and so it get bugged to oblivion. Should have it taken the "plug and play" option, b) or c), it could probably work out of the box, but then it would be violating an (unwritten) Debian policy, right? Do you see still think that the argument "for the sake of Plug & Play", "for the sake of the average user" should brandished in front of people as an excuse for not doing things properly? > You might as well get the issue documented in the RB BTS if you want, > I'll simply link to this thread where I clearly state that I think it's > a desirable feature which should be working by default. :) I don't agree with you here and if I get to see avahi being installed in a default GNOME install in Debian and will make damn sure that I get to see it removed. > The dep was strict because RB wouldn't start without it. Now it will > start, but with a warning. I'm quite sure you can get it to crash if > avahi isn't there though, but that's a bug. Then it's a bug, and it should be fixed in RB. > The avahi-daemon is nicely chrooted, and runs under a different user. > You just can't have the functionality of "plug'n'play" on a network > without any central server without listening at some point to > something... That functionality is not required for most desktop users. Period. For every user you can show up that requires that I can show you a user that doesn't. > > Really, do *almost all* rhythmbox users need to share music (and consequentely need > > ahavi)? > > That's not the point, the point is to make it easy to do so. And yes, > a lot of users share music between computers. Those people want that > to be simple. You can't cut every feature out because only 10% of the > users use it. No, that *is* precisely the point. We are talking about a default desktop install here. A default desktop install is not defined but what 10% of the users do, but it is defined based on what the majority does weighthing in the pros and cons of doing this and that. A network service, regardless of its implementation, is a no no. > It's not like you're running Rhythmbox on a firewall, and iptables is > still there, you can remove avahi, you can configure it not to start > etc. You already said that the default installation of avahi starts it (and actually, that's correct, since if a user installs it then it should be started), so typical users will not disable something that has been installed *per*default*. And, in any case, I *do* install GNOME on servers sometimes since I want to have a desktop to work with and not just a command line shell a GUI comes in handy for some tasks. As for iptables, you *do* know that the default Debian install does *not* setup a firewall or configure one at all after installation. I wonder why a default GNOME install does *not* install 'firestarter' (a GTK-based firewall configuration tool) Feature-bloat? (grin) Regards Javier [1] Yes, I know, "lies, damn lies, and statistics" [2] There are mp3 encoders in the Christian Marillat's archive (including lame) PS: If you've read to the end of this mail you have too much spare time... I recommend you spend some of that time taking a walk out in the sun away from computers and e-mail ;-)
Attachment:
signature.asc
Description: Digital signature