On Tuesday, 31 Aug 2004 06:20, Anders Ellensh�j Andersen wrote: > On Monday 30 August 2004 09:57, Alex Nordstrom wrote: > > Doh! My apologies. I just reread the report, and if I'm reading it > > correctly, the maintainer seems to think that a Recommends tag is > > sufficient. If that's the case (let me know and I'll add to the > > report), I completely agree with you; that is not sufficient given > > the cryptic command line error message, and the even more cryptic > > message box error (which is what most users will see). > > Exactly. Either the error message needs to be expanded (a lot!) or we > need full dependency on the plugin package. IMHO.
Alright, I appended some thoughts to the bug report, and Daniel Schepler kindly responded with his reasoning. I thought I'd discuss it a bit here again before potentially following up, just to maybe bounce a few ideas and hopefully not waste too much of the maintainers' time. On Monday, 6 Sep 2004 02:01, Daniel Schepler wrote: > Recommends is a strong dependency that is supposed to be satisfied in > "all but unusual installations". I'm curious what apt front-end > you're using that doesn't install recommended packages automatically, > or seemingly even notify you about the recommended packages. I'm > using aptitude, which I think handles this properly with the default > configuration. I tend to use either apt-get or Synaptic, but I didn't personally find it too difficult to find the cause of or solution to the situation; my concern is mainly for other users, such as the OP (and I don't know what front-end he used). One can argue the relative merits and demerits of different front-ends until one is blue in the face, but apt-get is still the most frequently cited front-end in howtos and other documents that inexperienced users are likely to encounter. (It does state recommendations in the default configuration, but without installing them automatically or emphasising their importance.) > Also, I interpreted that sentence of policy to mean "if A doesn't > provide any functionality at all without B, or the functionality > provided is insignificant, then A should list B in its Depends". Here, Daniel is referring to this sentence: "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality." http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps It is open to interpretation, and I don't think either interpretation is wrong. I think what Daniel is getting at is that you could use an MTA/MDA setup with KMail strictly as a reader of local mailboxes, thus eliminating the need for protocol support whilst having KMail provide a significant amount of functionality on its own in an unusual, but plausible setup. Perhaps a reasonable approach would be to add kdepim-kio-plugins as a dependency of the kdebase metapackage. It already depends on kdebase-kio-plugins, which has the following description: "This package includes the base kioslaves. This includes file, http, ftp, smtp, pop and imap." (I am not sure if it still does include IMAP, since kdepim-kio-plugins is also needed by KMail for IMAP support, but its list of installed files suggests it does at least have some responsibility for IMAP handling.) That would increase the likelihood of it being installed on most systems, but it could still be omitted for slimmed-down systems. Presumably by that same logic, it is already depended on by kdepim. I would guess, though, that a lot of users of KMail do not have the entire kdepim suite. Tricky. I see no clear-cut answer. My desire to have kdepim-kio-plugins included as a dependency of KMail is, I believe, no more nor any less valid from a policy point of view than the opinion that it should be kept as a recommends. Instead, I'd motivate it pragmatically, seeing that the current situation has caused confusion for some users, enough that they couldn't solve it themselves. The package in question weighs in at 369 KiB installed. To put it into perspective, this is 6% of the size of the kmail package (i.e. not including other libraries). Including it as a dependency seems to be a small price to pay to avoid confusion. As you can tell, I am not exactly sure about how to follow up, so I'd greatly appreciate some input. -- Alex Nordstrom http://lx.n3.net/ Please do not CC me in followups; I am subscribed to debian-kde.
