Re: Finding installed package files
From: Edward Diener (eldiener_no_spam_here_at_earthlink.net)
Date: 04/05/05
- Next message: Benjamin Johnston: "Re: Router stops routing after about two hours"
- Previous message: Moe Trin: "Re: Finding installed package files"
- In reply to: Moe Trin: "Re: Finding installed package files"
- Next in thread: Tim: "Re: Finding installed package files"
- Reply: Tim: "Re: Finding installed package files"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 05 Apr 2005 21:43:17 GMT
Moe Trin wrote:
> 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.
People agree on standards all the time. No reason to make a big issue
over this.
> 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.
I am not, repeat not, against 'man' pages. I am for making it easier to
find the important parts of what has been installed for certain
packages. I have now used 'rpm -ql somepackage' and do see that it very
nicely lists the files which have been installed and were they are.
Still I must pick out of all those files the ones that are pertinent to
my use. How much nicer it would be if the package itself were to somehow
tell me, as an installation option for some large packages, what was
pertinent. That is the whole gist of my OP and not that there is
something wrong with 'man' or 'rpm' or any other command.
>
>
>>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
No, I did not mean that. While I think documentation systems have
advanced immensely in the ways they can present and unify information
for the user beyond the simplicity of 'man' pages, I recognize their
worth when applicable. What I meant was that I was not suggesting that
every package create links somewhere to their 'man' pages, but rather
that large scale packages, post-installation, optionally be allowed to
create links to their most important features, ie. executables,
documentation which goes beyond 'man' page format, examples etc. etc.
>
>
>>>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.
There are many standard places to look but that doesn't mean I will know
what to find. Have you never installed a package which was applicable to
something you wanted to do as a user/programmer and wondered what/where
the information was to do what you wanted to do after the installation
was completed ? As a programmer this happens to me all the time and I
appreciate an installation which presents me with easy access to
executables, docs, examples, code, and the like.
>
>
>>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?
It is just telling one what the command are that make up the package. I
realize that 'rpm -ql apackage', looking at the results in /usr/bin ( I
suppose ), and then 'man' each one of the results there is probably just
as good in this simple scenario.
>
>
>>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)?
I know what is installed there from the Windows installation but if I
had not know that, I would have to pick out from 'rpm -ql python2.4' the
important files from a very big list. What is wrong with making it
easier for me ?
>
>
>>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.
Experience is great. Do you think Linux should be easily usable only by
the experienced ?
>
>
>>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.
No, I appreciate them for what they do.
>
>
>>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
- Next message: Benjamin Johnston: "Re: Router stops routing after about two hours"
- Previous message: Moe Trin: "Re: Finding installed package files"
- In reply to: Moe Trin: "Re: Finding installed package files"
- Next in thread: Tim: "Re: Finding installed package files"
- Reply: Tim: "Re: Finding installed package files"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
