I'm having a bit of trouble following your question, so let me first try to
restate it, so we can see if I 'm getting it right.
Right now, the "ldd" program is able to examine a single executable and
determine which shared libraries it depends on.
I believe you are suggesting that it would be desirable to have an
application that works like this:
1. Do an "ldd" examination of every executable on the system.
2. From the output of (1), compile a union list of all shared
libraries currently used on the system.
3. Compare (2) to the actual collection of shared libraries on the
system.
4. (Optionally) remove any shared libraries that are not used by
any executable present.
This is an interesting idea, and it is in principle doable. As far as I
know, no one has actually done it; the most likely candidate for someone to
be interested in doing this is one of the big Linux distributors (who might
find it most useful to tie it in with its own package-management system, as
a way to gain a competitive edge). Actually, any decent package-management
system can do this much more easily, by extending a bit the way it handles
dependencies (though there are "gotcha" risks with this approach if the
system contains *any* applications installed outside the package manager);
I think this is how Windows handles its analogous problem with managing DLLs.
Whichever way it were done, getting the details right would be a good bit
of work. And in practice, though the idea is interesting, I doubt the
actual utility of the application. The core set of .so libraries is pretty
stable, and the few specialized ones tend to be associated with
sufficiently specialized sorts of apps that someone who installs them would
know what was there.
These comments only address your concern about "the (sometimes quite large)
"libxxxx" packages". You also worry about "some rather "inevident" named
things". For these, the straightforward way to learn what the command does
is to consult its man page (the usual form of this suggestion is the
familiar "RTFM", but I'm far too polite to give you advice in that form) or
consult any of the many beginner's guides that exist in electronic and book
form. Once you know what a command does, you can decide whether or not to
leave it on the system.
In practice, distribution bloat has become something of a problem in Linux.
Naive installs of every distro I've looked at recently (including Debian,
alas) tend to lard up a system with a lot of unneeded stuff (not in the
form of surplus .so libraries, though -- this is really an applications
issue, not a shared-library problem). Today's bigger hard disks make it
less costly to put up with the bloat, but a more interactive install system
(Slackware used to have a nice one in the old days, around Slack 3.2 or so;
any chance it still does?) that made it easier to fine-tune an install
would be a help.
At , Heimo Claasen wrote:
>Indeed I do/did not really understand the effects of "make clean" and
>"make distclean", Richard (this _is_ a newbie list, isn't it?).
>Your explanation helps a bit, thanks.
>
>Thus "make distclean" would do the job like "uninstall", if I
>understand that right.
>And it depends on the individual programs/source-packages which one
>would work, right ?
>
>Now, on this other aspect of weeding out things that had been
>installed not by (what I would remember as "admin" or rather, root
>user) some specific intention or attention with installing/compiling
>one specific source "tar(gz)"-pack; but rather of what has been placed
>there when a "distro�" more or less automatically had installed say,
>"groups" of packages, e.g. "text tools".
>
>Sure the package manager of _that_ distro ould be of help for
>uninstalling too. That works simply enopugh with some "evident"
>packages - e.g., if you use one mailer and like it, it's evident that
>other mailer-packages could go.
>
>That hoever, is different with the (sometimes quite large) "libxxxx"
>packages, or some rather "inevident" named things.
>
>Not being a programmer, nor a systems professional, it is not at all
>evident, from the (sometimes arcane) short desciptions those package
>managing tools offer, to conclude to the package's meaning and
>usefulness or even necessity.
>
>"ldd" there, could give a hint - though, oh! sure!, only if all those
>"ldd" outputs then are cross-checked. Which is what I meant with "a
>hassle", doing exactly that, manually.<bg>
>
>But couldn't there be some kind of "sorting" prog/algorythm (please
>take "sorting" as quite large a term) which could do just that ?
>
>There should be, or at least it's thinkable to be do-able, a "listing"
>of "non-shared", so to say "singular" files (or even packages), at which
>you could then look at more in detail in order to decide if to delete
>them or not.
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA [EMAIL PROTECTED]
-------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
