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]