[SOLVED] Is there a way to reset /usr/local ?

trusktr · 2011-07-01 22:23:46

I've used /usr/local to test a program without installing it to my system with pacman. Prior to this, /usr/local was empty. I'm still learning Linux, but it seems that /usr/local (in the case of Arch) could be used as a playground since nothing gets installed there (at least not in my personal history of using Arch) so that is why I've tested in that location. The only downside is that I've had to add environment variables to my system, but that's no problem.

So currently, /usr/local contains files pertaining only to one single app (in the various directories, e.g. bin, lib, etc). It'd be neat if there was a way to reset /usr/local to factory standards so I don't have to dig through every folder and delete stuff manually.

Is there such an app/script?

If /usr/local isn't meant to be used in such a way, perhaps it'd be convenient to have a folder called /usr/test or something? Or is that what the /tmp folder is for?

THanks for the enlightenment!

Last edited by trusktr (2012-04-01 22:04:08)

olive · 2011-07-01 22:53:53

/usr/local is destinated for program you install yourself outside pacman. To use it /usr/local/bin must be in your path and you have to add /usr/local/lib to /etc/ld.so.conf. The structure of /usr/local is created by the filesystem package and contain the following empty directories (with rwxr-xr-x and owned by root).

/usr/local/
/usr/local/bin/
/usr/local/etc/
/usr/local/games/
/usr/local/include/
/usr/local/lib/
/usr/local/man/
/usr/local/sbin/
/usr/local/share/
/usr/local/share/man
/usr/local/src/

tomk · 2011-07-01 23:13:13

If you just want to get rid of everything in it, rm -r /usr/local and then reinstall the filesystem package.

lukaszan · 2011-07-01 23:47:26

'Factory standard' for Arch is, as you said, empty folder so you are good to remove everything.

I think it's OK to use it for testing, but bear in mind some apps may still install some files outside /usr/local, so it's probably better to build it in fakeroot and install via pacman.

olive · 2011-07-02 06:35:15

tomk wrote:

If you just want to get rid of everything in it, rm -r /usr/local and then reinstall the filesystem package.

I thought that also but the filesystem packages also contains /etc/password file and the like. Of course Arch will only show them as .pacnew but we should take care of that. I find it simpler just to recreate the empty structure. I agree that simply removing /usr/local/* might do as well, but If these empty directories are there, It should be for a reason.

When I install a source package (typically in /usr/local), I use a small script that

1) touch a file in /tmp
2) install the package
3) Find all files (exept in /home /tmp, etc...) that are cnewer that the file in 1).

This give me a reliable way to find what files have been created, modified by the package. The ctime is particularly useful because it is not user changeable.

trusktr · 2011-07-05 19:31:33

Thanks guys, good info.

@Olive That's interesting, good idea... Seems like it will only work with the very last package you installed though... If you install multiple packages you might lose track of the files. I guess you could touch files in /tmp and have them numbered as well as contain the package name. For example: "3-awesome-package". This would mean that awesome-package is the third package installed into /usr/local and all files with the (unchangeable) ctime that are created after "3-awesome-package" but before "4-another-package" could easily be spotted as belonging to the third package. . The package name prefix would serve only for your own record, and wouldn't be used in the script. If you want to delete all packages for "awesome-package" the script would do this:
* get ctimes of "3-awesome-package" and "4-another-package"
* rm [whatever goes here] [files that have ctime between 3 and 4]
So in essence, you aren't keeping track of what files the package contains since the ctime is all that matters. definitely a quick fix for deleting test apps.

Last edited by trusktr (2011-07-05 19:33:40)

olive · 2011-07-05 20:04:13

@trusktr. What you describe seems complicated and not much reliable. The stage 3) of my script "find the files that are cnewer than the file in /tmp" and make a log of the result in a file in /var/log that I leave there for reference. Of course I install only one package at a time. Your solution has the problem that if you touch in any way a file that belong to the package after it has been installed (because you or some tool modify a configuration file, for instance) you would loose the ability to track it (this would update the ctime to the actual time).

Removing a package is a little more complicated that you describe and cannot be fully automated. Some files are caches of files present in the filesystem (/usr/share/mime/mime.cache for instance) or are just modified by the installation of the package (/usr/share/info/dir) and contains information for several packages. You cannot just delete these files, you have to handle these properly.

Of course the good ways to do things would be to write an archlinux build script. But with my method, there is no additional work to install the package and, although it requires a little attention, it make at least the package removable.

Just for the info, I post my script here (it was written for my personal use with no man pages) (license: public domain):

http://pastebin.com/NTt6RPVE

trusktr · 2011-07-05 20:16:27

@Olive. Cool, thanks for that enlightenment. So for instance, if I install a package to /usr/local, then reset /usr/local, there might be stuff left in /usr/share that I also need to delete? I may have skipped that with the last package I manually deleted.

olive · 2011-07-05 20:24:28

When you install a package as root the package is free to install whatever it likes. Yes a lot put stuff not in /usr/local. Some packages make services to start at boot and modify several system files without telling it. With my method, I am sure to find any file on the system the package has modified. The worst that I have seen was a proprietary driver for a Samsung printer. It renamed openoffice and replace it by a suid wrapper to start openoffice as root Arghh! (it was not a virus, their driver was also for scanners and they want to integrate it with openoffice. They find easier to have root access to handle the scanner).

Last edited by olive (2011-07-05 20:25:01)

trusktr · 2011-07-05 20:29:58

wow! So with your script, this will only work for the immediate package being installed right? So if you install 2 packages, then you'd be able to tell what has changed based on those packages (you can no longer tell what is changed by one of the two packages) and if you delete the files, you'd delete all the files for both packages, right?

olive · 2011-07-05 20:36:28

But I first install the first package with my script, that make a log of the files belonging to the first package. Then I install the second packages and I have a log of the files belonging to the second package. I do not install two packages at once with my script.

Basicall you use my script the following way:

makeinstall -n <name of the package> <command to install the package>

the first argument default to the name of the current directory and the second default to "make install". For a typical source package, when you have compiled the package you just run makeinstall (instead of make install) in the source directory).

(the log file is created in /var/log/user-packages, this directory must be present in the system).

Last edited by olive (2011-07-05 20:47:31)

trusktr · 2011-07-05 20:41:43

So you can experiment with multiple packages at once? That's interesting! I'll have to learn some bash to understand your script better.

How do you differentiate between files changed/added/modified by package 1 vs package 2?

Last edited by trusktr (2011-07-05 20:42:13)

olive · 2011-07-05 20:54:28

I have edited my previous post to explain how to use my script. I do not understand your question. Say you want to install packages A and B. what is done is:

create /tmp/time_A
install package A
find files that are cnewer than /tmp/time_A and write the result to /var/log/user-packages/A

Then you install the second package B

create /tmp/time_B
install package B
find files that are cnewer than /tmp/time_B and write the result to /var/log/user-packages/B

/var/log/user-packages/A contains the files of the first packages and /var/log/user-packages/B contains the file of packages B. My script automate the process but only for one package. You have to run it two times (one time after the other) to install 2 packages. By the way installing two packages at the same time would not be a good idea.

Last edited by olive (2011-07-05 20:54:47)

lukaszan · 2011-07-05 21:11:48

Very interesting discussion.

What exactly is the advantage of those methods over writing a simple PKGBUILD and creating a proper package?

pkgname=blah
pkgver=0.1
pkgrel=1
arch=x86_64
license=wtfpl
source=blah-1.0.tar.bz2
package () {
  cd $srcdir
  ./configure --prefix=/usr/local
  make
  make DESTDIR=$pkgdir install
}

# makepkg
# pacman -U blah-0.1-1-x86_64.pkg.tar.xz

Simples.

Last edited by lukaszan (2011-07-05 21:12:57)

olive · 2011-07-05 21:27:25

Many packages are more complicated than that. You have to handle the mime cache, same for the desktop database cache, same for /usr/share/info/dir, and so on... Some packages are not so easy to install: it won't work if you try it with adobe reader for instance where you have to run an install script as root, same for google earth (where the AUR buildscript have to install everything by hand because no facility was given to create a package). My method works for any packages that have an installation script/program whatever it does or need to do.

Of course you can write a proper build script (that's what arch buildscripts are). But with my method you are sure to have a reliable log with no effort.

Last edited by olive (2011-07-05 21:30:50)

lukaszan · 2011-07-05 21:43:44

True. This is why for more complicated packages you can use AUR/ABS.

The ctime method is only relatively reliable as you may overwrite existing file from another, pacman installed package.

Unless you are really trying to install some extremely rare and freaky package, I'd recommend avoiding raw 'make install' and sticking to PKGBUILD.

trusktr · 2011-09-05 17:18:40

Interesting use of the log system olive! Never thought of using it before.

I agree with PKGBUILDS, lukaszan. In my case I don't want to recompile every module for each tiny update of the code I'm working on. I only want to recompile files where I've made changes to the code and not recompile an entire package. For example, I'm experimenting with buzztard from svn (buzztard-svn in the AUR), but it takes too long to re-install the package and all the dependancies each time I wish to try a small change.

How can PKGBUILDs be used in this scenario? (me = newbie)

Last edited by trusktr (2011-09-05 17:18:54)

trusktr · 2012-04-01 22:03:55

tomk's answer proved to be the easiest after all, but the other suggestions were very helpful. [SOLVED]

cfr · 2012-04-01 23:50:54

I know this is solved but can I put in a word for stow? (available in community)

If you make /usr/local owned by a non-root user (or at least /usr/local/stow), you can run make install with a suitable prefix under /usr/local/stow, and check it doesn't complain. If it tries to overwrite a file elsewhere, it won't be able to and will error out. You can then decide what to do. Assuming it goes OK, you can stow the package. This creates symlinks to the files under /usr/local/stow/<package-version>. To remove the package, you unstow it using stow -D. stow won't overwrite files without warning and keeps track of everything. The nice thing about this is that you can have multiple versions of a package under /usr/local/stow with only one of them actually installed. So if you install the new version of, say, clamav and it doesn't work, you can just stow -D the new version and stow the old version. (I get clamav from the repos now but I couldn't do that when I used OS X!) This is generally much quicker and easier than trying to do make uninstall and make install...

trusktr · 2012-06-19 03:23:09

@cfr Thanks, that's a very good tip!

Arch Linux

#1 2011-07-01 22:23:46

[SOLVED] Is there a way to reset /usr/local ?

#2 2011-07-01 22:53:53

Re: [SOLVED] Is there a way to reset /usr/local ?

#3 2011-07-01 23:13:13

Re: [SOLVED] Is there a way to reset /usr/local ?

#4 2011-07-01 23:47:26

Re: [SOLVED] Is there a way to reset /usr/local ?

#5 2011-07-02 06:35:15

Re: [SOLVED] Is there a way to reset /usr/local ?

#6 2011-07-05 19:31:33

Re: [SOLVED] Is there a way to reset /usr/local ?

#7 2011-07-05 20:04:13

Re: [SOLVED] Is there a way to reset /usr/local ?

#8 2011-07-05 20:16:27

Re: [SOLVED] Is there a way to reset /usr/local ?

#9 2011-07-05 20:24:28

Re: [SOLVED] Is there a way to reset /usr/local ?

#10 2011-07-05 20:29:58

Re: [SOLVED] Is there a way to reset /usr/local ?

#11 2011-07-05 20:36:28

Re: [SOLVED] Is there a way to reset /usr/local ?

#12 2011-07-05 20:41:43

Re: [SOLVED] Is there a way to reset /usr/local ?

#13 2011-07-05 20:54:28

Re: [SOLVED] Is there a way to reset /usr/local ?

#14 2011-07-05 21:11:48

Re: [SOLVED] Is there a way to reset /usr/local ?

#15 2011-07-05 21:27:25

Re: [SOLVED] Is there a way to reset /usr/local ?

#16 2011-07-05 21:43:44

Re: [SOLVED] Is there a way to reset /usr/local ?

#17 2011-09-05 17:18:40

Re: [SOLVED] Is there a way to reset /usr/local ?

#18 2012-04-01 22:03:55

Re: [SOLVED] Is there a way to reset /usr/local ?

#19 2012-04-01 23:50:54

Re: [SOLVED] Is there a way to reset /usr/local ?

#20 2012-06-19 03:23:09

Re: [SOLVED] Is there a way to reset /usr/local ?

Board footer