Re: Finding installed package files

From: Edward Diener (eldiener_no_spam_here_at_earthlink.net)
Date: 04/05/05 

Date: Tue, 05 Apr 2005 01:41:08 GMT

Moe Trin wrote:
> In article <i604e.13837$S46.2615@newsread3.news.atl.earthlink.net>,
> Edward Diener wrote:
>
>> No I want a folder on the desktop, or a directory in the filesystem,
>> which contains links to the most important information about the
>> installation.
>> This might be executables and/or documentation and/or sample files
>> and/or programmer IDE projects and/or whatever. The folder or
>> directory can even be named the same as the product just installed,
>> think of that !!!
>
> You really do need to spend some time discovering what's on the
> system now.

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.

> I suspect another problem is that you don't quite
> understand the difference that can exist between two "working"
> workstations used by individuals doing different tasks.

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

> Honestly, a
> lot of this has been thought out in depth.

Unless it is explained in depth why my general suggestion is so wrong, your
statement is meaningless.

>
>> Many packages have a single command, for which a 'man' page is
>> probably sufficient. But there are some packages, programming
>> languages, compiler implementations, large multi-purpose programs,
>> which could use what I suggest.
>
> [compton ~]$ rpm -qa | grep -c '^g'
> 23
> [compton ~]$ rpm -qd `rpm -qa | grep '^g'` | wc -l
> 366
> [compton ~]$ rpm -qd `rpm -qa | grep '^g'` | grep -c man
> 141
> [compton ~]$
>
> 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.

>
>> I would bet that out of the 1300 or so commands, 1200+ or so are the
>> single exe commands you speak about and need no links to them since
>> they >are just executed from a command window. But for the other 100
>> or so I see nothing wrong with program folders or directories
>> somewhere where more information about the key parts of the package
>> reside and are easily accesible.
>
> Let's look at the 1650 odd commands available to root. How many man
> pages
> do you think that might involve? Why do I see
>
> [compton ~]$ ls /usr/man/man* | wc -l
> 3094
> [compton ~]$
>
> and that's not including /usr/X11/man/ or /usr/local/man/ and so on.
> There is actually over 4200 man pages on this system. GNU really
> doesn't go in for man pages, so there are another 250+ info pages
> that are used as a "replacement".

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

>
>> As an example I installed the latest Python on Fedora 3. I know
>> Python comes with a command-line invocation, an Idle interpreter, a
>> help file, and a
>> small graphical program which searches Python module information
>> from the Internet. Post installation it would have been nice, as
>> Python does in Windows, to see a folder somewhere, which had links
>> to these four items so that I could access them immediately without
>> having to wonder where they are and what they are called.
>
> As noted elsewhere, I'm not using Fedora, but the last Red Hat CD
> listing I have (9.0.93 severn beta) had 22 packages to install
> 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 ?

>
>> And no matter what anyone says here, putting all the information
>> about Python, its language and its libraries, in a 'man' file or
>> many 'man' files reeks from the dark ages of computer usage and
>> programming.
>
> Actually, the package listing I have show exactly zero man pages for
> python. All of the stuff in in text files of some kind. And learning
> to use python isn't exactly falling off a log. Else, why do I find
> this:
>
> [compton ~/oreilly]$ grep -i python prdindex.txt.04.2005
> Python
> [_] Learning Python, 2nd Edition Dec 2003 $34.95
> [_] Programming Python, 2nd Edition Mar 2001 $54.95
> [_] Python & XML Dec 2001 $39.95
> [_] Python Cookbook, 2nd Edition Mar 2005 $49.95
> [_] Python in a Nutshell Mar 2003 $34.95
> [_] Python Pocket Reference, 3rd Edition Feb 2005 $9.95
> [_] Python Programming on Win32 Jan 2000 $34.95
> [_] Python Standard Library May 2001 $29.95
> [compton ~/oreilly]$

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:

1) the Python executable
2) the Python IDLE program ( Python IDE )
3) the Python documentation program
4) the Python keyword web search program

I am not picking on Python, since that is what the Windows installation
actually does and the Linux installation is following the normal Linux
guidelines of not doing it. There are plenty of others large scale packages
with multi-purpose functionality installed under Linux, and many of these
packages have graphical front-ends to make things easier for the user. 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. 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. 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.

>
>> But they very quickly become insufficient when dealing with
>> large scale information.
>
> That's why they are not the only documentation that is supplied with a
> package - especially the more complex ones. You _really_ don't expect
> a person to learn C from a man page, do you? Hell, I'm not a
> programmer,
> and my prowess in C is laughable (I don't get paid for it - if I need
> that, I ask one of the programmers), but why do I have five different
> text books for C, including the K&R second edition?

But one can learn how to use an IDE, or a complicated graphical program
which offers extremely useful functionality, from a good documentation
system that is light years beyond the simplicity of 'man' pages. Even
documentation for C or C++ itself can be put in an advanced documentation
system which the user can read via a good graphical front end.

I think you are suffering from the inability to realize that computer
systems have moved far beyond 'man' pages in their effort to document
computer technology. 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.

>
>> I have no idea what this electronic card browser is but if it has no
>> ability to search for a book based on common things like author,
>> title, or subject, then it probably isn't very good to start with.
>
> Oh, it does. It just has no instructions how, and it's really not
> intuitive. My point is that even a crappy little browser application
> is not learned intuitively. There really does need to be some
> instructions.
>
>> I think you know also this has nothing to do with Windows, Linux, or
>> anything else. I have used excellent documentation systems on
>> Windows and
>> I have used horrible documentations systems on Windows.
>
> Usually, you can limp along based on the help or man pages, but you
> won't get the most out of a system using documentation from a single
> source. Why do you think that publishers like O'Reilly are making a
> good living?

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 ? 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.

>
>> Sorry, it is a PITA to me no matter how you tout it. I do understand
>> that seasoned Linux user are used to it.
>
> s/Lin/*n/ It's not just Linux - check out the three quite
> different BSDs (and OSX which is based on FreeBSD). Check out Solaris
> which can also run on PC hardware. Check out the rather large family
> of branded UNIX.

Yes, I do realize that. There is nothing wrong with commands, but there is
also nothing worng with other methods which make things easy for the end
user to accomplish what they want.

>
>> I do not blindly install. I spent much time trying to remove what I
>> thought as garbage from my Fedora 3 base system recently.
>> Unfortunately so much of what I wanted to remove was used by other
>> elements that I wanted to keep.
>
> Before I installed Red Hat (2.0 back in 1995), I spent a bit over a
> week reading the documentation that came with it. And I'd been using
> Linux about a year before that (SLS and Yggdrasil), and various
> versions of UNIX for seven years before that. I then installed RH2.0
> on a test box, and spent close to a month just playing with it before
> I started using it seriously. Now, I know that Fedora doesn't come
> with anywhere near the documentation that the older distributions
> did; I'm assuming you are comfortable reading
> a *nix directory listing - this is the ISOs for RH9:
>
> 637763584 Mar 14 03:39 shrike-SRPMS-disc1.iso
> 676691968 Mar 14 03:43 shrike-SRPMS-disc2.iso
> 445153280 Mar 14 03:46 shrike-SRPMS-disc3.iso
> 104431616 Feb 28 22:53 shrike-docs-US.iso
> 668991488 Mar 14 03:26 shrike-i386-disc1.iso
> 677511168 Mar 14 03:30 shrike-i386-disc2.iso
> 508592128 Mar 14 03:35 shrike-i386-disc3.iso
>
> There were two other CDs, 'shrike-docs-APAC.iso' and
> 'shrike-docs-EMEA.iso' where APAC refers to AsiaPACific, and EMEA is
> EuropeMiddleEastAfrica.
>
>> Still I think Linux's ability to add, remove, and update software is
>> far superior to Windows, and it is mostly a pleasure to be able to
>> use it when necessary. It's just what happens after software is
>> installed ( actually
>> what does not happen ) that was the subject of my OP.
>
> Part of this is the enormous growth of Linux over the years, and the
> fact that there is no single entity that controls everything.
> Distrowatch lists over a hundred different Linux distributions. I
> honestly do remember when
> a "Linux distribution" was a bunch of floppies - for that matter,
> 4BSD was
> a single 1200 foot reel of half inch tape. Python (as an example)
> isn't
> even a part of Linux - it's a language that can run on Linux (and
> nearly
> all other operating systems). What you get in Python (or any other
> package) is generally from the developer of the package (poor choice
> of words - here I'm referring to the author, rather than the person
> at a distribution who took the source, and packaged it for Red Hat,
> Fedora, SuSE or who-ever).
>
>>> You are not mistaken - it's a way of life in the industry.
>>
>> A way of life that wastes enormous amounts of time and money.
>
> Tell me something new.
>
>> I have heard this all before and I have seen numerous organizations
>> and companies waste enormous time and resources training and
>> re-training programmers because nothing was ever written down.
>
> That is a rant for another place. The PHB is concerned with getting
> the product out the door. 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. If you were able to install on Windows, you can download from
http://www.tropicsoft.com/Components/RegularExpression/ and install any of
the exes and see that was true. Even when I work for a corporation I almost
always produce good documentation when others must use that I produce.

> Do you even
> comment the source? (That is one thing that instructors and peers have
> beaten into my head - I even try to do so sometimes.)

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 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.

Relevant Pages

  • Re: Finding installed package files
    ... > you appear to want is a file that lists executables and documentation. ... contains links to the most important information about the installation. ... > doubt others could finesse the command. ... I do understand that rpm has many options that tell me about a package. ...
    (alt.os.linux.redhat)
  • Re: Finding installed package files
    ... >, and who is going to supply this documentation. ... > is a package with the common man pages for the thousand odd common commands ... tell me, as an installation option for some large packages, what was ... >>a set of commands and 'man' pages, could produce such a directory to make it ...
    (alt.os.linux.redhat)
  • Re: metadocumentation (keyword help)
    ... > Python installation on a M$ operating system? ... revealed that the basic information about the PYTHONDOCS environment ... > finding/creating this documentation here. ...
    (comp.lang.python)
  • Re: bsddb package - Im confused, need help
    ... > I have some questions about the bsddb package that comes with Python 2.3 ... I've googled and read the documentation. ... Debian has a great package dependency system. ...
    (comp.lang.python)
  • Re: debian how-to
    ... do after installation, such as add mp3 playing ability, installing ... important skill for the new Debian user to have is howto find and use ... And not just documentation. ... I've thought a number of times that the package description aspect of the aptitude interface should include the path of the package concerned. ...
    (Debian-User)