Re: Finding installed package files

• Previous message: Rod Engelsman: "Re: Finding installed package files"
• In reply to: Edward Diener: "Re: Finding installed package files"
• Next in thread: Edward Diener: "Re: Finding installed package files"
• Reply: Edward Diener: "Re: Finding installed package files"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Mon, 04 Apr 2005 23:04:06 -0500

In article <U0m4e.355$go4.281@newsread2.news.atl.earthlink.net>,
Edward Diener wrote:

>Moe Trin wrote:

>I am sure all the things I need are on the system and have no doubt there
>are command line tools which will find for me whatever I need. Even given
>this argument why is it that you, as an experienced Linux user, can not
>imagine that Linux could be made easier for those who want to have the
>information about what was installed in a given package through the
>technique I mentioned above, or can not see the possibility of it having any
>beneficial usage.

Then you need to tweak Red Hat (or equal) or more likely the people behind
the Gnome and KDE desktop and convince them that your idea has merit. But
also think of the effort that will be needed to decide on a common format
(yeah, right), and who is going to supply this documentation. The man pages
that you are so vehemently against originally arrive from two sources. There
is a package with the common man pages for the thousand odd common commands
like 'ls' or 'more' or whatever. The other source is the individual package.
For example, the man pages for perl come with the perl packages.

>Of course I can understand that, but what has that to do with my argument
>for making installation information more easily accessible ?

The way things get done in *nix is that when you have an itch, you scratch
it.

>> There are 23 packages on this system whose name begins with a 'g'.
>> Included in those 23 packages are 366 documents, 141 of which are man
>> pages.
>
>So, what does that mean ? My argument was not to link to 'man' pages, and I
>am sorry if you believe that is what it is.

Above - and you missed my point that while there are 141 man pages,
there are also 225 other documents (and Red Hat only includes those that
it feels important - the source tarball often has a lot more).

>Again I am not interested in having links to 'man' pages.

Then define the new standard. GNU doesn't like man pages either, which is
why they produce 'info' pages. Have you even looked at that? Try

  info info instead of man man

>> python, and one of those packages was python-docs - about a third the
>> size of the base python package (1.8 megs).
                                   ^^^^^^^^^^^
>> [compton ~]$ zgrep python rpms.9.0.93-i386.gz | awk '{total += $5 };
>> END { print total }'
>> 10100288
>> [compton ~]$
>>
>> Hey, those 22 packages only totalled 10.1 Megs.
>Yes, and so ?

Seeing as how 18 percent of the package is documentation - have you looked
to see what that documentation might be?

>That is exactly my point. Python can not be explained in 'man' pages. So
>what one would expect is a form of help documentation much more integrated
>than separate 'man' pages can give one. What is the big deal about a Python
>installation creating links in a directory called 'Python' off the user's
>home directory which contains links to four items:

Well, it's generally because there is already enough clutter in home
directories. Read the Filesystem Hierarchy Standard, you'll discover there
is a standard place to look.

>My whole point is that any large scale package, which consists much more than
>a set of commands and 'man' pages, could produce such a directory to make it
>easier to find out how that package works.

=======
/usr/share : Architecture-independent data

Purpose

The /usr/share hierarchy is for all read-only architecture independent data
files. [30]

This hierarchy is intended to be shareable among all architecture platforms of
a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might
maintain a single /usr/share directory that is centrally-mounted. Note,
however, that /usr/share is generally not intended to be shared by different
OSes or by different releases of the same OS.

Any program or package which contains or requires data that doesn't need to be
modified should store that data in /usr/share (or /usr/local/share, if
installed locally). It is recommended that a subdirectory be used in /usr/share
for this purpose.

[...]

Requirements

The following directories, or symbolic links to directories, must be in /usr/
share

Directory Description
man Online manuals
misc Miscellaneous architecture-independent data

[...]

Specific Options

The following directories, or symbolic links to directories, must be in /usr/
share, if the corresponding subsystem is installed:

Directory Description
dict Word lists (optional)
doc Miscellaneous documentation (optional)
=======

>Even a small scale package of a half a dozen commands or so could produce a
>single file with the names and a on-line quickie explanation of the command
>just so the user has easy access to what was installed, but I do understand
>that this last may be easily accessible via rpm.

And this differs from a man (or info) page exactly how?

>But for large scale packages which do not operate strictly under the
>command-manpage idiom, I think my suggestion would be very helpful even to
>Linux gurus.

Have you looked to see what all is included in package $FOO (the python
groups for example)?

>But one can learn how to use an IDE, or a complicated graphical program
>which offers extremely useful functionality,

It offers the functionality that the program author allowed for. Now, look
up thread, and tell me what icon or pulldown menu you are going to use to
give the histogram of commands I have recently used. Yes, it took me nine
pipes to get the result I needed, and I really don't expect a first or
second year CS student to be able to roll that off the top of the head, but
that's experience.

>I do not say that it is not valuable to buy computer books and read them. I
>am a programmer myself and I have two large bookcases of computer books and
>product manuals. But one can also present large scale documentation online
>which makes using and programming computers much easier.

Hope your book cases are large - my wife goes ballistic when I stop at a
book store. There are 16 books in front of me between the monitors, and the
book shelves behind me are _large_ But I tend to prefer on-line docs
because they tend to be more up to date, and I can use the tools that I have
to search for information. Have you looked at the HOWTOs? On this system,
there are 491 of those, totalling just under four million words - about
11,900 printed pages. There are also 118 FAQs - totalling another 2300
pages of text. Care to guess how I know that? Hint: three commands.

>I agree. And why do you think that Microsoft distributes MSDN help systems
>and Eclipse distributes Java help systems with their products, both large
>scale and easy to use documentation systems which dwarfs the simplicity of
>single 'man' pages ?

Boy, you _really_ have it in for man pages.

>It is certainly not because they hate 'man' pages and it is certainly not
>because they do not realize that one can buy computer books from O'Reilly
>and numerous other publishers, but because they actually want to make it
>EASIER ( sorry, couldn't resist ) for computer users to use their software.

Yes, and at what cost? Most computer users today are really pushing their
envelope to use the on/off switch, and really don't know what they are
doing. If they were even vaguely trained, do you think we'd have anything
near as much problems with malware? Look at the spam you receive. Last
time I did, I identified four pieces out of ten thousand that might not
be sent from an 0w3n3D windoze box.

>> Documentation - even when it's a contractual deliverable ALWAYS takes a
>> distant second place. But then, do _you_ provide full documentation with
>> the software you write?
>
>Actually I do.

You are rare.

>If you were able to install on Windows,

Other than a few 'dove bar' mice, I got rid of microsoft products at home
back in 1992. The last place I worked at that even had windoze boxes was
back in 1989. Where my wife works, they have a lot of windoze boxes, but
she's been using Linux at her desk, and only has access to a box running
XP/SP2 for the damn PowerPoint docs she sometimes gets in email, in place
of a page of text. She avoids windoze as much as possible.

>I do to some extent when I work but I do not distribute my own source
>otherwise. But I do not believe that one should have to, or need to, read
>source code to understand how to use a product.

I do next to no higher order language programming - it's not my job. I do
use shell scripts rather extensively, and those that I write either have
simple documentation, or are commented, but that's mainly so that I can
figure out WTF the script is trying to do six months after I wrote or
modified it last.

>I feel the whole way of understanding software by having to read source code
>is the greatest fallacy in computer programming, and the biggest waste of time.

I'm glad you are able to trust all software that way - I work at an R&D
facility, and we're just slightly paranoid. As such, you'd better believe
that we have people reading source.

        Old guy

• Previous message: Rod Engelsman: "Re: Finding installed package files"
• In reply to: Edward Diener: "Re: Finding installed package files"
• Next in thread: Edward Diener: "Re: Finding installed package files"
• Reply: Edward Diener: "Re: Finding installed package files"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]