Ken Irving wrote: > On Tue, Apr 07, 2009 at 01:34:57PM -0400, Barclay, Daniel wrote: >> John Hasler wrote: >>> Daniel writes: >>>> Debian packages should have some standard place to go to to see those >>>> latter kinds of information. .... >>> /usr/share/doc/<packagename> contains README.debian, the upstream README, >>> and any other documentation provided by upstream other than man pages and >>> info files. >> Yes, I know. But there's little or no consistency, and I don't recall >> seeing one that said things like what daemons were started, or what commands >> are newly available. > > You're arguing what the policy should be. Debian is based on policy, > but perhaps it's better to specify the minimum level of policy that > results in a working system.
What about usability? If system is working and had zero documentation, that certainly wouldn't be acceptable, so clearly some degree of usability is required. Obviously, the degree that is needed or desirable is arguable. > What you want is a convenience for you, And other users. > but an amount of work and > necessary maintenance for many people, not to mention policing and > bug-reporting to get all packages to comply. But that's just like for any other part of Debian policy. > The information you seek is available. But frequently not without significant digging. > To get a hint of 'what commands > are available' I often do: > > $ dpkg -L | grep bin/ Yes, I know about that. But that doesn't tell you, say, which executables meant for you to run directly vs. which are internal, so you have to dig further for that. What is so hard to understand (or, rather, get across) about the value of conveying (conveniently) to the user the key aspects of what just changed about the system (what is now available) after installing a package? On Windows several generations back, when you installed a package, it typically left open the package's new program group folder (or something), so the use could see what (menu-based) commands were newly available from installing the package. Now (at least Windows 2000 and XP), installing a typical package adds the package's submenu at the end of the list, so, again, there's a known place the user can look to see what's newly available. (And some packages separate the primary programs or menu commands from others (e.g, those for configuration or uninstallation).) Obviously the details of those mechanisms don't apply (at least not directly) to Linux, but the high-level feature (making it easy to see the relevant changes) does. > The source is available, e.g., > > $ apt-get source <package> > > so use it. Debian users are not supposed to have to look at the source to figure out what something does. (Debian policy requires that all packages have descriptions. Debian policy requires that all commands have manual pages, doesn't it?) > File a bug if you find a problem with the documentation, scripts, code, > etc. of a particular package, but be reasonable, and realize you're asking > somebody to do work and pay attention to your issue. I'm trying to reduce the occurrence of problems, not just wait for each instance and then fix only that instance. Daniel -- (Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]
