Re: Finding installed package files

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

Date: Fri, 08 Apr 2005 00:22:31 GMT

james wrote:
> "Edward Diener" <eldiener_no_spam_here@earthlink.net> wrote in message
> news:rYb5e.1770$go4.370@newsread2.news.atl.earthlink.net...
>> Tim wrote:
>>> Edward Diener <eldiener_no_spam_here@earthlink.net> posted:
>>
>> You have missed my point almost entirely, which has little to do
>> with 'man' pages, documentation, or most of the other things you
>> argue in your response. I realize now that I can find which files
>> are part of a particular installed passage using the rpm command. My
>> point was simply, to find out which files out of all those installed
>> as part of a package are apropos to what I want to do using that
>> package, and to have easy access to those files, especially the ones
>> not in my path. If a package installs 20+ files, a very common thing
>> in the packages which I see, I want to know which are the ones I use
>> to accomplish what I want to do with that package.
>>
>> My point, repeated in various ways in my response, but evidently too
>> difficult or too irritating for others to grasp, is a very simple
>> one. I do not mind if others really do not find it helpful to users.
>> But at least they should say so and why. If, however, others see
>> this as being helpful to Linux users, especially those who are not
>> experienced in Linux commands, shells, etc., why not agree that
>> Linux could be made easier by having installation programs actually
>> "point" to those files, post-installation, which are useful to users
>> in order to use the product.
>>
>> This can not be a revolutionary idea in the year 2005, unless Linux
>> demands that:
>>
>> 1) Nothing should be made easier for users of the system, because
>> that is an absolute law of all Linux distributions.
>> 2) No ideas which may be useful can be even considered from Windows
>> ( or any other OS ) because that would be tantamount to admitting
>> that Windows has some good ideas about how to do things and Linux
>> can not possibly admit to that in any way.
>>
>> I apologize for the sarcasm, but I thought my point is very easy to
>> grasp and to see others denigrate it with silly remarks such as "you
>> want to know what toys you've got to play with" makes me angry. The
>> resistance to all groups to change is usually great but the
>> resistance among Linux users seems a bit ridiculous.
>>
>
> Edward, I think what everyone has been trying to tell you is that
> using Linux requires a different mindset.

I understand that and I was not trying to change how Linux does things. I
was only suggesting a possibly user-chosen addition to how Linux does
things.

> I have used Linux in various forms over the years and really like the
> way some things are done. And I also use Windows. And for "me", I
> don't expect Linux to be the same experience as Windows.
> Here is a link that is really good at answering questions for new
> users of Linux:
>
> http://www.linuxquestions.org/
>
> I have found answers to a lot of questions there and also using
> Google. There is so much documentation on line for Linux and Linux
> apps that a new user should have no problems finding the answers to
> their questions. One other thing, nearly every app I have installed
> in Fedora Core 3, has a web link to the author's website. There you
> can find updates, howto's and all kinds of things.
> One thing you mention is packages installing a lot of files and
> finding out what those files do or how you use them(I hope I
> understand you correctly here.)

You have partially misunderstood me. I do not want to know what every file
in an installation is about. I do want to know which files in some large
installations are the ones I can use to accomplish whatever the package
entails. This includes not only the main executables, but perhaps also the
documentation, samples, and whatever is instrumental to using the package.

> As a Windows programmer, I can tell
> you that Windows apps. install a lot of files too. And there is no
> way that you will ever see documentation on how each of those files
> are used in your application. It would be impossible to list what
> each dll and other needed files are there for.

Since you know how Windows does things, then you know that when a product is
installed it has the option to create a program group in which each item in
that group points to some important file in the installation. Usually having
this program group is helpful to the Windows user because the key files of
that program group are shown with links to those files. As an example, in
Microsoft's own Visual Studio .NET 2003 creates a program group with these
items: link to the Visual Studio 2003 IDE, link to the MSDN documentation,
subfolder which contains links to common tools which one uses in conjunction
with the using the IDE. Now imagine if this was not provided. I would then
be searching for the executable and its command line for invoking the IDE,
for the executable and its command line for invoking the documentation, and
both the names of the supporting tools and their commands, in order to use
them. By creating a program group Microsoft is making it easier for me to
instantly use those areas of the installation which matter.

Now I realize that Linux is different, that it places the files of an
installed package in generally regular places, and that I can use the rpm
command to find out the names of those files and where they are. For most
commands there are 'man' pages to tell me the way to use that command. I do
not argue with that. I can also see that for a great number of packages, all
one needs to see or know is the name of a single command, and then one just
invokes that command and uses the 'man' page to understand how it works. I
have no argument with this tried and true method.

But there are packages for Linux which, much like the installation of Visual
Studio .NET 2003, create a large number of commands, documentation, and
whatever else etc. In order to use these packages effectively one has to
find out what the important parts of the installation are simply by studying
the list of files which the package installs. I do not think this is that
easy, but perhaps experienced Linux users know ways in which they instantly
understand in such a large scale package what and how to use it. My simple
suggestion, however, is that, for such large scale Linux installations, a
program group on the desktop, or even some directory beneath the user's home
if you will, be optionally creatable which contains links to certain salient
files of that installation which make it easier to use the package.

Please notice I am not trying to change the way installations work. I am
only suggesting an optional improvement, which can be chosen by the user
when the command to install the large scale package is given, and then only
for packages which want to use that option, to make it easier for the end
user to see the most important parts of what has been installed after the
installation is finished.

Also realize that the way Windows installations usually work is to create
the program group, but it is certainly not mandated that the installation
program do so. Similarly, with my suggestion, the way Linux packages will
almost certainly usually work will be to not create a program group ( or
directory ), since most Linux packages are fairly simple usages. But some
will, especially large scale packages whose usage involves much more than
either a single command or a simple 'man' page, and that will be very
beneficial to the Linux user, especially those who are not as experienced as
your Linux guru.

I hardly deem this suggestion as either revolutionary or complicated. I do
not mind that many experienced Linux users find it unnecessary. But I do
mind when they can not even understand why it might be beneficial to others
even if they feel that the benefit is not worth changing anything in the way
that Linux installations are generally done.

Relevant Pages

  • Re: bits/news from the users of Debian?
    ... "Le bottin des jeux Linux" speaks about 800 Linux games and i hope that's growing. ... I start with Debian, then test Mandrake because it seem's at this time very complicated. ... I think graphics interface for installation is a good thing: you have make a good job! ... I use Debian Sid and I have experiment a lot of problem some years ago because i install too recent package on Sid which are not well tested. ...
    (Debian-User)
  • Re: Finding installed package files
    ... >> Linux does things. ... >> every file in an installation is about. ... >> whatever is instrumental to using the package. ... >> command line for invoking the IDE, ...
    (alt.os.linux.redhat)
  • 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)
  • Knoppix ATI Catalyst installation problem
    ... I'm a linux newbie and it's my first message in this newsgroup. ... Some months ago I successfully made a Knoppix HD installation (it became ... Unlikily the command had no effect (it couldn't read the file list or ... Tailored kernel module for fglrx not present in your system. ...
    (comp.os.linux.setup)
  • Re: Why 6 CDs for 10.1? Curious
    ... which gets you the package description for each package. ... the actual _files_ each package contains, the command becomes 'rpm -qpl' ... Most of the "popular" Linux distributions are on multiple CDs, ... browsers, a few news readers, a few mail tools, who knows how many text ...
    (alt.os.linux.suse)