On Wed, 09 Feb 2005, John R. McPherson wrote: > > If you didn't even KNOW you were supposed to also install freepats, and you > > are using apt-get, please switch to Synaptic or Aptitude (or even dselect). > > These will handle Recommends in a much saner way for the end-user. > > Telling people which front-end they should use is a little rude.
Not really, no. I used very nice and polite language, and I have reason to believe it is pertinent to the report (the two other times I had this complain it was because of apt-get usage by users that did not know better), so I am not doing it "just for the heck of it" or anything like that. The fact that apt-get ignore Recommends *is* a deficiency that most users are *not* aware of (and which has been a pain for quite a while now). I will not break any packages to work around it. You are perfectly justified to, if you want, reopen and reassign this bug to the "apt" package (or open a new one there). In the past, the reply from the apt maintainers when the issue was raised (of that time, I believe there are other people maintaining apt now) was that "apt-get was never supposed to be used as anything but a debugging front-end, and to use aptitude or dselect instead..." Anyway, all of this, assumes you are using apt-get, which might not be the case. But still, if you ignore a "Recommends", you are asking for less than the full functionality of a package. In timidity's case this only means you need to edit the config file. For other packages, it might mean it cannot deal with certain data-types, etc. I can't see any bugs in the timidity packaging in this case, either. > From > http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps > ########### > Depends > This declares an absolute dependency. A package will not be > configured unless all of the packages listed in its Depends field > have been correctly configured. > > The Depends field should be used if the depended-on package is > required for the depending package to provide a significant > amount of functionality. The current reading for this is "the package breaks horribly, segfaulting or otherwise failing to run because of missing dynamic libraries or essential data files, *and* there is nothing to be done to fix the issue other than installing the missing packages". > Recommends > This declares a strong, but not absolute, dependency. Which is the case here, since timidity does not in any way require freepats. You just need to edit the config file. It is quite easy to imagine a situation where the user does NOT want freepats installed (i.e. for any non-joke installation of TiMidity++, since freepats is not good enough for anything but listening to piano solos...), too. Why should I make it impossible for people to remove freepats from their system, if TiMidity++ does NOT require it to work? > Surely you agree that, as configured by the default timidity.cfg, freepats > "is required for the depending package to provide a significant amount > of functionality." Otherwise maybe freepats could use debconf or > something to only add that line to timidity.cfg when it gets installed? For freepats (and any other package) to modift timidity.cfg, I would have to stop shipping it inside the deb. That means I have to add a lot of code to the timidity package for little gain, AND that it is likely that I would now have to deal with the far worse scenario of freepats screwing up someone's custom timidity.cfg file. Sorry, this is an alternative that I am not prepared to implement at this time (and likely, never will be). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
