On Thu, 16 Dec 2010, Ville Skyttà wrote: > On Thursday 16 December 2010, Jon Masters wrote: >> On Wed, 2010-12-15 at 23:57 +0200, Ville Skyttà wrote: >> But how many packages nowadays require a man page reader simply because >> > they install man pages? >> >> Well, since it's a guideline, it's worth discussion. Sure there's only >> 18 in your list, but that sounds more like a bug than a feature. >> Similarly, for docs in HTML format we could probably do with some kind >> of dependency suggestion (I'm not sure what the Fedora version of RPM >> recommended way of doing dependency level "suggestions" is now). I would >> think that would be the ideal, to recommend these things but not require >> them to be installed if it's just documentation files. >> >> I think the policy should be to somehow recommend the additional bits, >> then you can add "but not require" in place of the existing wording. > > I disagree, in my opinion even a recommendation in this context would be too > much. I think the line when to use recommendations should be drawn to > something that adds features or makes software work better/more efficiently. That's largely the problem with soft dependencies: nobody knows what they really mean in different contexts (automated vs interactive install, different spins/desktop environments and all) FWIW, I've played with the idea of adding some sort of "content handler" indications to packages - it does make a certain amount of sense, at least for some packages such as the aforementioned html docs and manual pages. But it can't be any kind of real dependency (you dont want to drag in a web browser just because "pam" contains html documentation), and it probably couldn't be automatically generated for there would be lots of rather hysterical false positives. For packages containing only documentation, it could even be reasonable to have a hard-requirement on a reader (eg html-only documentation is not particularly useful without something that can render it, not to mention postscript, pdf etc) - Panu - -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
