File Management

File Management

[Paul Kraus]

Obviously software is always better installed from source. This creates
binaries that are system specific. However this represents the problem
of software removal. I notice some software by default will install into
/usr/local then dump everything under one directory (windows style-the
source install for samba is a good example). You can uses switches to
put these files in the correct bin lib etc folders. So if you follow the
standard(usings the systems bin/etc/sbin/man/var folders) how can you
effectively remove a piece of software without having a list of all the
files and paths of every app you installed. This is the only drawback to
Linux I have found. Of course RPMs/dpms are away around this but lets
omit pre-packaged software.

Paul Kraus
Network Administrator
PEL Supply Company
216.267.5775 Voice
216-267-6176 Fax
www.pelsupply.com

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: File Management

[pa3gcu]

On Wednesday 18 September 2002 19:20, Paul Kraus wrote:
> Obviously software is always better installed from source. This creates
> binaries that are system specific. However this represents the problem
> of software removal. I notice some software by default will install into
> /usr/local then dump everything under one directory (windows style-the
> source install for samba is a good example). You can uses switches to
> put these files in the correct bin lib etc folders. So if you follow the
> standard(usings the systems bin/etc/sbin/man/var folders) how can you
> effectively remove a piece of software without having a list of all the
> files and paths of every app you installed. This is the only drawback to
> Linux I have found. Of course RPMs/dpms are away around this but lets
> omit pre-packaged software.

If ones installes programs from *.tar.gz archives after compiling one can 
simply delete the source dir and its contents, you are then left with the 
executable of course, when you want to "uninstall" a program reinstall the 
source and simply type make uninstall, in some instancies it may be nessasary 
to exectute a file called ./configure or even ./autogen.sh those files create 
a Makefile, once the Makefile is created one can then do;
make uninstall .

Mind you some older archives did not have that approch, but i guess in the 
modern day kernels they would not compile anyway, so we can safely say;

cd /to/source/dir
make uninstall


>
> Paul Kraus
> Network Administrator
> PEL Supply Company
> 216.267.5775 Voice
> 216-267-6176 Fax
> www.pelsupply.com


-- 
Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: File Management

[Edgar Alwers]

On Wednesday 18 September 2002 21:30, pa3gcu wrote:

> On Wednesday 18 September 2002 19:20, Paul Kraus wrote:
> > Obviously software is always better installed from source. This creates
> > binaries that are system specific. However this represents the problem
> > of software removal.

There is a little programm, installwatch, which seems to record exactly 
everything which was installed in an directory, and allows to remove 
completly in the case you want to uninstall:

Quote: (heavy shortened ! )
--------------------------------------

TITLE:		Using Installwatch as a Package Manager
LFS VERSION:	Any
AUTHOR:		Robert Park <feztaa@shaw.ca>

SYNOPSIS: 
	Use installwatch to keep track of what files got installed when you compiled
	something from source. Includes an easy method for removing those files,
	packaging those files up, and installing said packages.

HINT:


One big problem with LFS is that there is no package management system.  This
means that it is a *HUGE* pain in the butt to uninstall something, since there
is no record of what got installed where, and by what program.


Requirements
------------

You'll need to download installwatch, which you can get from one of these
locations:

http://asic-linux.com.mx/~izto/checkinstall/installwatch.html
http://proyectos.glo.org.mx/checkinstall/installwatch.html

If both these sites are down, try this one (but only as a last resort):

http://www.google.ca/search?hl=en&q=installwatch+izto+0.6.3&meta=

You'll also need my 'nuke' script, which is used for uninstalling software,
among other things. You can get that here:

http://members.shaw.ca/feztaa/projects/nuke

4. Using Installwatch.

Now I'm going to show you how to use installwatch to create the logfiles that
will be used by the nuke script.

When you are reading installation instructions for something, and you see 
"make install", you'll want to replace that with this:

##--CODE--##
installwatch -o /var/install/programname-version make install
##--CODE--##

5. Using Nuke.

The nuke script has many uses, the first and foremost of which is to
uninstall software by analyzing installwatch logfiles.

Uninstalling software is extremely easy with the nuke script, you simply give
it a logfile from /var/install, and it will remove the software from your
system, and then create a logfile in /var/uninstall telling you how the
uninstall went.
------------------------------------
unquote

This are hints from the project "Linux from the scratch", and I hope it will 
help you. Up to now, I have not used installwatch, but I am intending to do 
it.
Regards,
Edgar


-- 
--------------------------------
Dr.-Ing. Edgar Alwers
Mailto: edgaralwers@gmx.de
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: File Management

[Arthur Othieno]

pa3gcu wrote:

> On Wednesday 18 September 2002 19:20, Paul Kraus wrote:
> 
>>Obviously software is always better installed from source. This creates
>>binaries that are system specific. However this represents the problem
>>of software removal. I notice some software by default will install into
>>/usr/local then dump everything under one directory (windows style-the
>>source install for samba is a good example). You can uses switches to
>>put these files in the correct bin lib etc folders. So if you follow the
>>standard(usings the systems bin/etc/sbin/man/var folders) how can you
>>effectively remove a piece of software without having a list of all the
>>files and paths of every app you installed. This is the only drawback to
>>Linux I have found. Of course RPMs/dpms are away around this but lets
>>omit pre-packaged software.
>>
> 
> If ones installes programs from *.tar.gz archives after compiling one can 
> simply delete the source dir and its contents, you are then left with the 
> executable of course, when you want to "uninstall" a program reinstall the 
> source and simply type make uninstall, in some instancies it may be nessasary 
> to exectute a file called ./configure or even ./autogen.sh those files create 
> a Makefile, once the Makefile is created one can then do;
> make uninstall .
> 
> Mind you some older archives did not have that approch, but i guess in the 
> modern day kernels they would not compile anyway, so we can safely say;
> 
> cd /to/source/dir
> make uninstall

Note that there are some programs distributed as tarballs that may not 
have the `uninstall' rule in their Makefile. This makes them harder to 
remove but not impossible (<- one word that doesn't deserve a place in 
your vocabulary)...

Meet "checkinstall". This nifty program keeps a tab of all installed 
programs on your system, making it easier for you to manage them 
(Installing/Unistalling), by keeping a record of all write-actions 
performed when you do a `make install' or similar. Get it at 
http://proyectos.glo.mx/checkinstall/

To install the package, do:
	tar xvzf checkinstall-X.Y.Z.tg

	cd checkinstall-X.Y.Z

	make
	su (root passwd here)
	make install
	checkinstall
	exit

To install a new package you would normally have to do
	./configure
	make
	su (root passwd here)
	make install
	exit

With checkinstall installed, you have to replace the `make install' step 
with `checkinstall' so that it (checkinstall) knows what has been 
installed andthus makes it easier to remove. So, you would have 
something like:
	./configure
	make
	su
	checkinstall
	exit

Hope that helps ;)

Arthur


> 
>>Paul Kraus
>>Network Administrator
>>PEL Supply Company
>>216.267.5775 Voice
>>216-267-6176 Fax
>>www.pelsupply.com
>>
> 
> 



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

RE: File Management

[Paul Kraus]

This link does not work.
I did a google search of "Linux checkinstal" and found a home page but
the app actually creates an rpm after the source is compiled. 

-----Original Message-----
From: linux-newbie-owner@vger.kernel.org
[mailto:linux-newbie-owner@vger.kernel.org] On Behalf Of Arthur Othieno
Sent: Thursday, September 19, 2002 9:09 AM
To: pa3gcu@zeelandnet.nl
Cc: Paul Kraus; linux-newbie@vger.kernel.org
Subject: Re: File Management




pa3gcu wrote:

> On Wednesday 18 September 2002 19:20, Paul Kraus wrote:
> 
>>Obviously software is always better installed from source. This 
>>creates binaries that are system specific. However this represents the

>>problem of software removal. I notice some software by default will 
>>install into /usr/local then dump everything under one directory 
>>(windows style-the source install for samba is a good example). You 
>>can uses switches to put these files in the correct bin lib etc 
>>folders. So if you follow the standard(usings the systems 
>>bin/etc/sbin/man/var folders) how can you effectively remove a piece 
>>of software without having a list of all the files and paths of every 
>>app you installed. This is the only drawback to Linux I have found. Of

>>course RPMs/dpms are away around this but lets omit pre-packaged 
>>software.
>>
> 
> If ones installes programs from *.tar.gz archives after compiling one 
> can
> simply delete the source dir and its contents, you are then left with
the 
> executable of course, when you want to "uninstall" a program reinstall
the 
> source and simply type make uninstall, in some instancies it may be
nessasary 
> to exectute a file called ./configure or even ./autogen.sh those files
create 
> a Makefile, once the Makefile is created one can then do;
> make uninstall .
> 
> Mind you some older archives did not have that approch, but i guess in

> the
> modern day kernels they would not compile anyway, so we can safely
say;
> 
> cd /to/source/dir
> make uninstall

Note that there are some programs distributed as tarballs that may not 
have the `uninstall' rule in their Makefile. This makes them harder to 
remove but not impossible (<- one word that doesn't deserve a place in 
your vocabulary)...

Meet "checkinstall". This nifty program keeps a tab of all installed 
programs on your system, making it easier for you to manage them 
(Installing/Unistalling), by keeping a record of all write-actions 
performed when you do a `make install' or similar. Get it at 
http://proyectos.glo.mx/checkinstall/

To install the package, do:
	tar xvzf checkinstall-X.Y.Z.tg

	cd checkinstall-X.Y.Z

	make
	su (root passwd here)
	make install
	checkinstall
	exit

To install a new package you would normally have to do
	./configure
	make
	su (root passwd here)
	make install
	exit

With checkinstall installed, you have to replace the `make install' step

with `checkinstall' so that it (checkinstall) knows what has been 
installed andthus makes it easier to remove. So, you would have 
something like:
	./configure
	make
	su
	checkinstall
	exit

Hope that helps ;)

Arthur


> 
>>Paul Kraus
>>Network Administrator
>>PEL Supply Company
>>216.267.5775 Voice
>>216-267-6176 Fax
>>www.pelsupply.com
>>
> 
> 



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie"
in the body of a message to majordomo@vger.kernel.org More majordomo
info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: File Management

[Heimo Claasen]

This latgest on "uninstall" in this thread is bordering the question I
had earlier on "weeding out" unneeded things.

Uninstalling a program compiled on a machine seems to work like that
indeed.
BTW, I got another command (syntax) told:
   > make clean
   > make distclean
(this from in the dir from which it was installed or rather,
"./configure" was run.)

Next question then is where to find (and delete) obsolete files which
had been installed collaterally (however automatically, package
driven or not) earlier ?

For instance, "ldd <prog-name>" apparently lists a number of files
"referenced" [sic, <g>] by that _one_ program.

But it's clearly a hassle to have this done for _all_ programs in order
to find out those some files the use of which is not shared.  (One of my
fatter, though far from complete installations has almost 60,000
files...)

// Heimo Claasen // <hammer at revobild dot net> // Brussels 2002-09-18
The WebPlace of ReRead - and much to read  ==>  http://www.revobild.net

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: File Management

[pa3gcu]

On Thursday 01 January 1970 00:00, Heimo Claasen wrote:
> This latgest on "uninstall" in this thread is bordering the question I
> had earlier on "weeding out" unneeded things.
>
> Uninstalling a program compiled on a machine seems to work like that
> indeed.
>
> BTW, I got another command (syntax) told:
>    > make clean
>    > make distclean

It is not clear to me if you understand what 'make clean' and 'make 
distclean' do, clean delete's mainly *.o files created when 'make' is 
completed.
distclean cleans out everything created by both ./configure and make.
 
>
> (this from in the dir from which it was installed or rather,
> "./configure" was run.)
>
> Next question then is where to find (and delete) obsolete files which
> had been installed collaterally (however automatically, package
> driven or not) earlier ?
>
> For instance, "ldd <prog-name>" apparently lists a number of files
> "referenced" [sic, <g>] by that _one_ program.

O wait, dont delete what ldd says is used by a program, they are libarys of 
which are shared by other programs as well, delete those and your system will 
be brought to its knees.

>
> But it's clearly a hassle to have this done for _all_ programs in order
> to find out those some files the use of which is not shared.  (One of my
> fatter, though far from complete installations has almost 60,000
> files...)

If you run a system where you constanly install "user" progams from tar 
archives, then you the system operator (superuser) have control of where the 
programs are placed, remember one thing it is normal practice for user 
programs to be placed in /usr/local/bin or /usr/local/sbin, most archives do 
just that if one simply uses ./configure without options, or the Makefile 
which is supplied within the archive is used without editing it.
That has always been Linux pratice, this allow's a better overview of 
installed programs.

If a program uses a config file then "mainly" it will be placed into 
/usr/local/etc altho' that is not always the case, the other place left over 
for config files is then /etc which should not cause to many problems to find 
config files you want to delete.

The use of /usr/local is/has and always be a point of discussion, some 
distro's do not have /usr/local in ones path, one needs to edit ones $PATH 
and add it otherwise programs installed in /usr/local/* will not be found.

Other's say /usr/local is obsolite, remembering what i have mentioned above i 
consider /usr/local "far from obsolite" and indeed the distribution slackware 
also considers it "far" from obsolite.

Its the place one installes his/her own programs and then knows where they 
are instead of having them dropped in all over the system making a cleanup 
almost impossable.
 
>
> // Heimo Claasen // <hammer at revobild dot net> // Brussels 2002-09-18
> The WebPlace of ReRead - and much to read  ==>  http://www.revobild.net

-- 
Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: File Management

[Heimo Claasen]

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.

// Heimo Claasen // <hammer at revobild dot net> // Brussels 2002-09-20
The WebPlace of ReRead - and much to read  ==>  http://www.revobild.net

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: File Management

[Ray Olszewski]

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			  ray@comarre.com
-------------------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: File Management

[Heimo Claasen]

Thanks, Steven and others who replied to this thread.

I suspect I have to go with this indeed:
> Your best bet would probably be to just rely on your package manager.
Hmm.

Interesting, nevertheless:
> This initially sounds like a good idea.  In fact, I once went as far as
> actually writing such a script.  Unfortunately, you quite quickly
> hit a problem: ldd doesn't actually report all of the libraries
> used by a particular program.  You've said you're not a programmer, so
> I'll spare you the details, but it is possible for a program to
> specify while it's running that additional libraries should be linked
> in. This is used by most programs which support plug ins, for instance.
> Unfortunately, it isn't possible in general to get a complete list of
> such libraries just by looking at the program in question, and so you
> can't build an accurate list of which libraries are in use.

Which latter condition explains some of the never-ending troubles with
installing (application) programs.

Understandable, sure, that one wouldn't like to re-invent all those
wheels.
Less understandable that there is no (at least, moral) obligation to
"declare" used bits and pieces from somewhere else in a/the "system".
Result is lots of newbie frustration.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs