Re: avahi-daemon
On Fri, Mar 03, 2006, Javier Fernández-Sanguino Peña wrote:
> (IMHO this dicussion is reaching to a point in which it should move to
> d-devel instead, but I'll keep it here)
Uh, please don't move it there, in the contrary, this discussion
already reached flame-level, and no arguments are coming in. I'd
rather get things settled down, and solutions implemented.
I made some efforst in listing solutions here, and in the bug report MS
opened. I don't want the burden of following a new flame in
debian-devel@ .
> > 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.
You've cut what I said, I explained why I didn't like that. Please
don't cut like that, that's quoting out of context.
I said it woud require code to disable preferences when avahi isn't
there, the documentation would still refer to the features, but the
user wouldn't have them, and a dialog would be ugliest: it would
introduce package level information within an application.
Yes, some of this can be done (patch for the runtime part welcome, file
it, I'll check it, send it upstream, apply 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.
Please, send a patch. The code assumes it's there right now (and would
crash if it wasn't in the past, hence the previous Depends dependency),
feel free to enhance it to support a missing avahi at runtime nicely.
> 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.
What a nice integration level, while you're at it, mention the
./configure switches. We're talking desktop users here, that is "works
out of the box".
> 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.
You can stop right here, I'm not arguing it's useful on all computers,
or even on the average computers. Besides, we're only considering
computers where rhythmbox is installed.
> 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?
This is mixing the MP3 encoder problem with a completely unrelated one.
Please install sound-juicer, it will encode Ogg vorbis just fine, and
by default.
> 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're mixing issues. The fact stuff is patent encumbered and can't
enter Debian has nothing to do with the current discussion. It would
certainly be nice if we could legally permit people to install MP3
encoders, like MacOSX does.
> > 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.
Please do follow your opinions, I have no problem with that. I took
the decision of the current deps with my own judgment, and hold to it
after what I've read or heard on the subject. I wouldn't oppose any
superior ruling to my judgment, which might be technically incorrect.
> > 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.
Feel free to report it, and to provide a patch. It doesn't change the
fact that the Recommends is there for functional reasons.
> 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.
It's not about *most* desktop users, do most kernel users need the vfat
filesystem? Or IPv6 support? Does it have possible holes in it?
That argument was made numerous times, and completely misses the point.
> > 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.
That's the same argument, see my response above.
> > 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.
Yes, and it is my intent that it starts by default when RB is
installed. Your point being?
> 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)
I suggested iptables because all people in the "don't pull avahi" camp
aim at security, and iptables would solve their security problem.
> 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 ;-)
I'm doing my final pass on the deb-sec part of this discussion, I don't
intend to participate much further, no new arguments are popping up.
--
Loïc Minier <lool@dooz.org>
Current Earth status: NOT DESTROYED
Reply to: