Re: [gentoo-user] Installing outside of Portage cruft removal
I'd like to install the latest miro from their nightlies and that means installing manually without an ebuild. I've always avoided this because I don't want files spread across my system without an easy way to remove them. I've also always wanted to set up a good cruft removal script for keeping my system clean (I'll admit that takes me in the hobbyist direction) and I'm thinking the two might work well together. I could temporarily install apps without an ebuild and use a cruft removal script to remove them. What do you guys think of this? Do you know of a good cruft removal script? If you can install your apps into a specific location, I'd use xstow. emerge xstow cd ~/install/myapp-1.2.3 ./configure --prefix=/usr/local/stow/myapp-1.2.3 make make install cd /usr/local/stow xstow myapp-1.2.3 myapp-1.2.3 is installed into /usr/local/stow/myapp-1.2.3, but xstow created symlinks into the /usr/local hierarchy, so it looks as if it were directly installed there. No need to add /usr/local/stow/myapp-1.2.3/bin to the PATH and such. Use xstow -D myapp-1.2.3 to remove the symlinks if you want to uninstall, then remove /usr/local/stow/myapp-1.2.3. That would still leave anything installed outside of /usr/local (/etc for example) right? - Grant
Re: [gentoo-user] Installing outside of Portage cruft removal
Am Montag, 16. Februar 2009 19:33:11 schrieb Grant: If you can install your apps into a specific location, I'd use xstow. emerge xstow cd ~/install/myapp-1.2.3 ./configure --prefix=/usr/local/stow/myapp-1.2.3 make make install cd /usr/local/stow xstow myapp-1.2.3 myapp-1.2.3 is installed into /usr/local/stow/myapp-1.2.3, but xstow created symlinks into the /usr/local hierarchy, so it looks as if it were directly installed there. No need to add /usr/local/stow/myapp-1.2.3/bin to the PATH and such. Use xstow -D myapp-1.2.3 to remove the symlinks if you want to uninstall, then remove /usr/local/stow/myapp-1.2.3. That would still leave anything installed outside of /usr/local (/etc for example) right? No. All the symlinks will be in /usr/local or subdirectories of it (or more general: in the parent directory of the stow dir). Bye... Dirk signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Installing outside of Portage cruft removal
If you can install your apps into a specific location, I'd use xstow. emerge xstow cd ~/install/myapp-1.2.3 ./configure --prefix=/usr/local/stow/myapp-1.2.3 make make install cd /usr/local/stow xstow myapp-1.2.3 myapp-1.2.3 is installed into /usr/local/stow/myapp-1.2.3, but xstow created symlinks into the /usr/local hierarchy, so it looks as if it were directly installed there. No need to add /usr/local/stow/myapp-1.2.3/bin to the PATH and such. Use xstow -D myapp-1.2.3 to remove the symlinks if you want to uninstall, then remove /usr/local/stow/myapp-1.2.3. That would still leave anything installed outside of /usr/local (/etc for example) right? No. All the symlinks will be in /usr/local or subdirectories of it (or more general: in the parent directory of the stow dir). I thought running something like '.configure --prefix=/usr/local make make install' could still install files outside of /usr/local. No? - Grant
Re: [gentoo-user] Installing outside of Portage cruft removal
Am Montag, 16. Februar 2009 21:31:39 schrieb Grant: I thought running something like '.configure --prefix=/usr/local make make install' could still install files outside of /usr/local. No? As long as you don't specify otherwise, no. Everything will be under the directory specified by --prefix unless you specify exceptions, see ./configure --help. Bye... Dirk signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Installing outside of Portage cruft removal
Grant wrote: I'd like to install the latest miro from their nightlies and that means installing manually without an ebuild. I've always avoided this because I don't want files spread across my system without an easy way to remove them. I've also always wanted to set up a good cruft removal script for keeping my system clean (I'll admit that takes me in the hobbyist direction) and I'm thinking the two might work well together. I could temporarily install apps without an ebuild and use a cruft removal script to remove them. What do you guys think of this? Do you know of a good cruft removal script? If you can install your apps into a specific location, I'd use xstow. emerge xstow cd ~/install/myapp-1.2.3 ./configure --prefix=/usr/local/stow/myapp-1.2.3 make make install cd /usr/local/stow xstow myapp-1.2.3 myapp-1.2.3 is installed into /usr/local/stow/myapp-1.2.3, but xstow created symlinks into the /usr/local hierarchy, so it looks as if it were directly installed there. No need to add /usr/local/stow/myapp-1.2.3/bin to the PATH and such. Use xstow -D myapp-1.2.3 to remove the symlinks if you want to uninstall, then remove /usr/local/stow/myapp-1.2.3. Wonko
Re: [gentoo-user] Installing outside of Portage cruft removal
Jesús Guerrero ha scritto: On Mon, January 26, 2009 17:48, Mike Kazantsev wrote: On Mon, 26 Jan 2009 08:41:52 -0800 Grant emailgr...@gmail.com wrote: What do you guys think of this? Do you know of a good cruft removal script? Yep, there's quite good one in gentoo itself. Basically, you'll need to write a short config for it, consisting of lines like cruft name, cruft src uri and a few more lines if you'll need to pass some extra parameters to configure/make/install. It'll build the package in a sandbox, then transfer it to destination, memorizing every change it did and preventing collisions and config overwrites. Just put that config script into an ebuild file and use portage to build it - as simple as it gets ;) If you have to learn to write anything, I suggest learning to write ebuilds instead which will probably be a better long term solution. That way you can reuse that knowledge in your Gentoo experience and you don't need a cruft remover either because you can just emerge -C your program. Ehm, that's what Mike was suggesting, albeit wittily :) m.
Re: [gentoo-user] Installing outside of Portage cruft removal
On 26 Jan 2009, at 22:51, Grant wrote: ... So for example, miro needs xine to play videos. If I ./configure miro with --prefix=/usr/local, it will install to /usr/local/miro or similar? Yes. Read the configure options for the app you're installing. It might also have a --libprefix or similar that you need to change, too. Then I would need to point it to xine and possibly others since it wasn't configured like --prefix=/ ? Usually the configure scripts should find stuff installed in the main part of the system. Is all this done as root? `./configure make` as user, `make install` as root (sudo?). ... in any case save the source tree for further refference, or just to be able to make uninstall. Couldn't I just uninstall with 'rm -rf /usr/local/miro' ? I don't know about miro, but often foo will install not install a directory /usr/local/foo but instead files /usr/local/food /usr/ local/foobar. These will get intermingled with files /usr/local/bard /usr/local/barfoo, so `make uninstall` is used to uninstall the files cleanly. I believe that configure scripts for some programs (e.g. mplayer?) may also sometimes install config files in /etc - I think `make uninstall` will remove these, but I get the impression from your earlier posts that you may find this undesirable. Nevertheless, it is worth experimenting with compiling by hand using this method - I would consider it an essential Linux skill and it will give you an insight into things around which Portage is merely a wrapper. Stroller.
Re: [gentoo-user] Installing outside of Portage cruft removal
If you are installing a package by hand and wants to revert back to
the previous state, best is to :
- when you ./configure it, use the various --prefix directives (do a
./configure --help for information on that)
- when you want to remove, make uninstall in the source dir (so don't
remove it!)
- if it does not have a remove, usually if you install it inside
/home/${username}/whatever, then removing that is fine.
Best thing though is to write an ebuild and then Portage will sandbox
the build so it knows every file that has been installed.
The package knows where to link to when it goes into the ./configure
stage and won't act like windows, installing stuffs into registry or
the like ... everything's nicely contained inside /lib and /share
folders (except /etc files ...which you can safely ignore them there -
those are just text files and you'll know where they are anyway if you
intend to configure miro)
Re: [gentoo-user] Installing outside of Portage cruft removal
If you are installing a package by hand and wants to revert back to
the previous state, best is to :
- when you ./configure it, use the various --prefix directives (do a
./configure --help for information on that)
- when you want to remove, make uninstall in the source dir (so don't
remove it!)
- if it does not have a remove, usually if you install it inside
/home/${username}/whatever, then removing that is fine.
Best thing though is to write an ebuild and then Portage will sandbox
the build so it knows every file that has been installed.
The package knows where to link to when it goes into the ./configure
stage and won't act like windows, installing stuffs into registry or
the like ... everything's nicely contained inside /lib and /share
folders (except /etc files ...which you can safely ignore them there -
those are just text files and you'll know where they are anyway if you
intend to configure miro)
Thanks everyone. I've never been open to manual compile/installation
but I can give it a try now.
- Grant
Re: [gentoo-user] Installing outside of Portage cruft removal
On Tue, Jan 27, 2009 at 4:34 PM, Grant emailgr...@gmail.com wrote:
If you are installing a package by hand and wants to revert back to
the previous state, best is to :
- when you ./configure it, use the various --prefix directives (do a
./configure --help for information on that)
- when you want to remove, make uninstall in the source dir (so don't
remove it!)
- if it does not have a remove, usually if you install it inside
/home/${username}/whatever, then removing that is fine.
Best thing though is to write an ebuild and then Portage will sandbox
the build so it knows every file that has been installed.
The package knows where to link to when it goes into the ./configure
stage and won't act like windows, installing stuffs into registry or
the like ... everything's nicely contained inside /lib and /share
folders (except /etc files ...which you can safely ignore them there -
those are just text files and you'll know where they are anyway if you
intend to configure miro)
Thanks everyone. I've never been open to manual compile/installation
but I can give it a try now.
Once you learn the basics, most programs are the same (configure/make)
and it's not so bad. Obviously the advice to read the README/INSTALL
files is golden, they will almost always tell you what you need to
know.
On my home PC I used to tri-boot OS/2 (my first love), Win95
(wintendo) and Slackware (version 2 or 3?), so back then I think
everything had to be manually configured and compiled pretty much. I
guess it all seems kind of obvious once you already know how to do it.
We've come a long way since then. :)
[gentoo-user] Installing outside of Portage cruft removal
I'd like to install the latest miro from their nightlies and that means installing manually without an ebuild. I've always avoided this because I don't want files spread across my system without an easy way to remove them. I've also always wanted to set up a good cruft removal script for keeping my system clean (I'll admit that takes me in the hobbyist direction) and I'm thinking the two might work well together. I could temporarily install apps without an ebuild and use a cruft removal script to remove them. What do you guys think of this? Do you know of a good cruft removal script? - Grant
Re: [gentoo-user] Installing outside of Portage cruft removal
On Mon, 26 Jan 2009 08:41:52 -0800 Grant emailgr...@gmail.com wrote: What do you guys think of this? Do you know of a good cruft removal script? Yep, there's quite good one in gentoo itself. Basically, you'll need to write a short config for it, consisting of lines like cruft name, cruft src uri and a few more lines if you'll need to pass some extra parameters to configure/make/install. It'll build the package in a sandbox, then transfer it to destination, memorizing every change it did and preventing collisions and config overwrites. Just put that config script into an ebuild file and use portage to build it - as simple as it gets ;) -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature
Re: [gentoo-user] Installing outside of Portage cruft removal
On Mon, January 26, 2009 17:48, Mike Kazantsev wrote: On Mon, 26 Jan 2009 08:41:52 -0800 Grant emailgr...@gmail.com wrote: What do you guys think of this? Do you know of a good cruft removal script? Yep, there's quite good one in gentoo itself. Basically, you'll need to write a short config for it, consisting of lines like cruft name, cruft src uri and a few more lines if you'll need to pass some extra parameters to configure/make/install. It'll build the package in a sandbox, then transfer it to destination, memorizing every change it did and preventing collisions and config overwrites. Just put that config script into an ebuild file and use portage to build it - as simple as it gets ;) If you have to learn to write anything, I suggest learning to write ebuilds instead which will probably be a better long term solution. That way you can reuse that knowledge in your Gentoo experience and you don't need a cruft remover either because you can just emerge -C your program. -- Jesús Guerrero
Re: [gentoo-user] Installing outside of Portage cruft removal
What do you guys think of this? Do you know of a good cruft removal script? Yep, there's quite good one in gentoo itself. Basically, you'll need to write a short config for it, consisting of lines like cruft name, cruft src uri and a few more lines if you'll need to pass some extra parameters to configure/make/install. It'll build the package in a sandbox, then transfer it to destination, memorizing every change it did and preventing collisions and config overwrites. Just put that config script into an ebuild file and use portage to build it - as simple as it gets ;) I suppose you and Jesus are right, but what about cruft removal? Are you saying Gentoo is 100% cruft-free? I've got a lot of junk in /etc and especially ~/.* - Grant
Re: [gentoo-user] Installing outside of Portage cruft removal
Grant wrote: What do you guys think of this? Do you know of a good cruft removal script? Yep, there's quite good one in gentoo itself. Basically, you'll need to write a short config for it, consisting of lines like cruft name, cruft src uri and a few more lines if you'll need to pass some extra parameters to configure/make/install. It'll build the package in a sandbox, then transfer it to destination, memorizing every change it did and preventing collisions and config overwrites. Just put that config script into an ebuild file and use portage to build it - as simple as it gets ;) I suppose you and Jesus are right, but what about cruft removal? Are you saying Gentoo is 100% cruft-free? I've got a lot of junk in /etc and especially ~/.* - Grant Portage doesn't remove files from /etc and should never touch any home directory. As far as I know, portage never puts anything in a home directory either. You have to clean out /etc and home directories yourself. Portage does do a good job of removing all the other files tho. If it puts it there, it will remove it if you unmerge a package. Dale :-) :-)
Re: [gentoo-user] Installing outside of Portage cruft removal
On Mon, 26 Jan 2009 09:35:13 -0800 Grant emailgr...@gmail.com wrote: I suppose you and Jesus are right, but what about cruft removal? Are you saying Gentoo is 100% cruft-free? I've got a lot of junk in /etc and especially ~/.* Oh, that's not a bug, it's a feature (C) some_unknown_company AFAIK portage won't remove any changed (by hand) files in CONFIG_PROTECT paths, and I've certainly can't remember a package, which installs anything into ~. Of course, if you'll launch installed app it'll create some config, temp files, etc, but that'll only affect the paths to which it has access, and that's probably only your ~ and /tmp. And as soon as portage will start to clean up your home from app-created files like, say, some documents you've spent weeks working on, it'll certainly make it to the top-10 evil linux viruses out there. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature
Re: [gentoo-user] Installing outside of Portage cruft removal
On (26/01/09 09:35) Grant wrote: What do you guys think of this? Do you know of a good cruft removal script? Yep, there's quite good one in gentoo itself. Basically, you'll need to write a short config for it, consisting of lines like cruft name, cruft src uri and a few more lines if you'll need to pass some extra parameters to configure/make/install. It'll build the package in a sandbox, then transfer it to destination, memorizing every change it did and preventing collisions and config overwrites. Just put that config script into an ebuild file and use portage to build it - as simple as it gets ;) I suppose you and Jesus are right, but what about cruft removal? Are you saying Gentoo is 100% cruft-free? I've got a lot of junk in /etc and especially ~/.* - Grant Hi Grant, Check 'man qfile' - there're examples for finding cruft files. HTH. Rumen
Re: [gentoo-user] Installing outside of Portage cruft removal
What do you guys think of this? Do you know of a good cruft removal script? Yep, there's quite good one in gentoo itself. Basically, you'll need to write a short config for it, consisting of lines like cruft name, cruft src uri and a few more lines if you'll need to pass some extra parameters to configure/make/install. It'll build the package in a sandbox, then transfer it to destination, memorizing every change it did and preventing collisions and config overwrites. Just put that config script into an ebuild file and use portage to build it - as simple as it gets ;) I suppose you and Jesus are right, but what about cruft removal? Are you saying Gentoo is 100% cruft-free? I've got a lot of junk in /etc and especially ~/.* - Grant [snip] You have to clean out /etc and home directories yourself. Exactly. Nothing to help me along? I'll check out qfile, but I'm surprised there isn't a good script for this. I'm the only one interested in a filesystem audit? - Grant Portage does do a good job of removing all the other files tho. If it puts it there, it will remove it if you unmerge a package. Dale
Re: [gentoo-user] Installing outside of Portage cruft removal
Grant wrote:
What do you guys think of this? Do you know of a good cruft removal
script?
Yep, there's quite good one in gentoo itself.
Basically, you'll need to write a short config for it, consisting of
lines like cruft name, cruft src uri and a few more lines if you'll
need to pass some extra parameters to configure/make/install.
It'll build the package in a sandbox, then transfer it to destination,
memorizing every change it did and preventing collisions and config
overwrites.
Just put that config script into an ebuild file and use portage to
build it - as simple as it gets ;)
I suppose you and Jesus are right, but what about cruft removal? Are
you saying Gentoo is 100% cruft-free? I've got a lot of junk in /etc
and especially ~/.*
- Grant
[snip]
You have to clean out /etc and home directories yourself.
Exactly. Nothing to help me along? I'll check out qfile, but I'm
surprised there isn't a good script for this.
I'm the only one interested in a filesystem audit?
- Grant
Portage does do a good job of removing all the other files tho. If it
puts it there, it will remove it if you unmerge a package.
Dale
There is a script on the forums that is supposed to clean out /etc. I
am attaching a copy of it. I have no idea if it still works or if it
will completely destroy your system. I would search for the thread or
go through the script to make sure it doesn't mess up something.
I do wish there was a option for cleaning out /etc but then again, that
could be dangerous too.
Dale
:-) :-)
#!/bin/bash
VERSION=3.11
###
# etcportclean
# Isaac Chanin, 2005
#
# Refer to 'etcportclean --help' for information.
#
# This code is not copyrighted and is in the public domain.
# It comes with no warranty of any kind, explicit or otherwise.
###
# Exit codes
SUCCESS=0
NOT_ROOT=10
BAD_ARGS=20
WORLD_CHECK_FAIL=30
SANITY_CHECK_FAIL=31
DUPLICATE_FAIL=40
DUPLICATE_WARN=41
NO_FILES=50
MISSING_DEPENDENCY=51
CANNOT_DOWNLOAD=60
BAD_HASH=61
# Directory where portage files are kept
FILES_DIR=/etc/portage
# Where etcportclean is on the web
WEB=users.wpi.edu/~chanin/scripts/etcportclean
# Files we (optionally) look at
files=( package.keywords package.unmask package.mask package.use
package.cflags package.cxxflags package.ldflags )
# Messages about files
messages=( unnecessary keywords needlessly unmasked packages needlessly
masked packages unnecessary use flags repeat cflags repeat cxxflags
repeat ldflags )
# Generally needed progs
neededprogs=( sed awk grep egrep sort uniq tail head xargs )
if [ $UID -ne 0 ] ; then
echo You must be root to run this script.
exit $NOT_ROOT
fi
function usage()
{
echo etcportclean v$VERSION - clean, check and stabilize
$FILES_DIR/package.*
echo
echo usage:
echo $prog [flags]
echo
echo Flags may be any of:
echo-cNNN, -rN, -wN, -dN, -v[N], -V[N], -u[N]
echo Where N is either 0 or 1.
echo
echo -c Check: This flag allows you to indicate, on the command
line, which
echo files you would like to check. The order is as follows
(package.):
echo `echo ${fil...@]} | sed 's/\ /\n/g' | awk -F . '{ print $2
}' | xargs`.
echo So, for example, -c0011000 would check ${files[2]} and
${files[3]}.
echo Defaults to asking the user (unless the file does not exist.)
echo
echo -r Remove: This flag allows you to toggle automatic removal of
unnecessary
echo entries. It only affects keywords, unmask, and mask checking.
The others do
echo not have any automatic removal mechanism. Defaults to asking
the user, if
echo there is anything to remove.
echo
echo -w World Check: This flag allows you to turn 'emerge -puD
world' checking on
echo or off. It defaults to on if you are checking any of keywords
unmask or mask.
echo NOTE: Turning off 'emerge -puD world' checking may cause
etcportclean to miss
echo lines that could otherwise be removed. Defaults to on.
echo
echo -d Duplicate Check: This flag allows you to turn duplicate
checking on or off.
echo It does not affect use, cflags, cxxflags or ldflags duplicate
checking.
echo NOTE: For certain exotic configurations you may have to turn
off duplicate
echo checking. One example would be if you have multiple accepted
keywords for
echo a single package. Defaults to on.
echo
echo -v Verbose: This flag makes etcportclean verbose about what it
is doing. If
echo you find what you think is a bug, try to get some more
information by using
echo this or -V. Defaults to off.
echo
echo -V Very Verbose: This flag makes etcportclean even more verbose
Re: [gentoo-user] Installing outside of Portage cruft removal
Grant schrieb am 26.01.2009 18:35: I suppose you and Jesus are right, but what about cruft removal? Are you saying Gentoo is 100% cruft-free? I've got a lot of junk in /etc and especially ~/.* No it isn't, but this is very hard to automate cruft detection via scripts as you still have to decide yourself if a file is really needed or not. It is very easy to compare all the files on the filesystem with the list of files controlled by portage. But everything that is left over is not cruft, because there are files you put somewhere yourself or files that are not controlled by portage but are essential to the system. So you have to use some kind of ignorelist to exclude files that are not under portage control but needed. As you see it is still you who has to decide if a file is cruft or not. I have done something minimalistic that evolved over time and that fits my needs. I long refrained from attaching it here, but as this question comes up so often I think I will share it. I am not a programming guru so there might be bugs or other stuff done in a poor way so don't come here and complain if the script has killed your kitten. I will attach the cruft script written in perl and as an example the ignorelist I use for my system and the list of cruft files that remain as false positives. You have to customize the ignorelist yourself so it does a proper job on your system. I have tried to make the script user friendly but it surly isn't so you may have to tinker with it a bit. The script actually does not delete anything it just presents you a list of files that contains all files on the filesystem minus the files controlled by portage and minus the files you have ignored. There is also another cruft script that you may get from overlays but I don't remember where. If you search the archives you may find it as it has already been mentioned here. Regards, Daniel #!/usr/bin/perl # # # ### # Script: cruft-control.pl # Version: 0.19 # Autor:Daniel Pielmeier ### use strict; use diagnostics; use warnings; use File::Find; #use Text::Diff; use Getopt::Long qw (:config posix_default gnu_compat pass_through no_ignore_case_always); # Directories my $destdir = (); my $confdir = (); my $searchdir = (); my $vdb_path = (); # Files my $cruft = cruft.txt; my $oldcruft = oldcruft.txt; my $diffcruft = diffcruft.txt; my $negcruft = negcruft.txt; my $systemfile = systemfile.txt; my $contentlist = contentlist.txt; my $packagefile = packagefile.txt; my $ignorelist = ignorelist.conf; # Variables my $uid = `id -u`; chomp $uid; my $debug = (); my $ignoreitem = (); my @systemfile = my @ignorelist = (); my @contentlist = (); my @packagefile = (); my $prev = (); my @cruft = (); my %packagefilecheck = (); my @negcruft =(); my %systemfilecheck = (); my $help = DESCRIPTION: This script tries to find files not under the control of the package manager. The resulting list of files should normally not called cruft as proper detection of cruft is almost impossible. So this script does not offer functions to delete any files reported. In general it searches all files in the filesystem. It uses an $ignorelist where files and directories can be specified which will be ignored from the search to avoid obvious false positives. Then it gets the files which are listed in CONTENTS from vdb_path where the files installed by the package manager are stored. This two resulting lists are compared with each other to get the files which are not under the control of the package manager. The resulting list is stored in the $cruft file. Additionally if available it compares the results with an older cruft file called $oldcruft and creates $diffcruft out of it to find out changes which occuring when merging and unmerging programs. This is useful when you are not sure about the files listed in an initial search so one can just track the changes. Carefully examine $cruft and/or $diffcruft. Deleting wrong files which are essential for a working system may break it. You are responsible for your system. This script will just make it easier to to detect files which are probably not needed on the system. Optionally it writes debug info in form of $systemfile, $contentlist, $packagefile and $negcruft. $systemfile lists all files found in the filesystem excluding the files and directories from $ignorelist. $contentlist lists all paths to the CONTENT files only useful to see which packages are installed. $packagefile lists all files under the control of the package manager. $negcruft this are the files which are in $packagefile but not in $systemfile because they are not present in the filessystem or ignored by the ignorefile. CONFIGURATION: For $0 you configure the path to configuration files which for now is only $ignorelist. and the path to generated output
Re: [gentoo-user] Installing outside of Portage cruft removal
On Mon, Jan 26, 2009 at 12:17 PM, Grant emailgr...@gmail.com wrote: What do you guys think of this? Do you know of a good cruft removal script? Yep, there's quite good one in gentoo itself. Basically, you'll need to write a short config for it, consisting of lines like cruft name, cruft src uri and a few more lines if you'll need to pass some extra parameters to configure/make/install. It'll build the package in a sandbox, then transfer it to destination, memorizing every change it did and preventing collisions and config overwrites. Just put that config script into an ebuild file and use portage to build it - as simple as it gets ;) I suppose you and Jesus are right, but what about cruft removal? Are you saying Gentoo is 100% cruft-free? I've got a lot of junk in /etc and especially ~/.* - Grant [snip] You have to clean out /etc and home directories yourself. Exactly. Nothing to help me along? I'll check out qfile, but I'm surprised there isn't a good script for this. I'm the only one interested in a filesystem audit? - Grant Portage does do a good job of removing all the other files tho. If it puts it there, it will remove it if you unmerge a package. Dale I think if you enable auditing in the kernel and emerge sys-process/audit you can see the access history of any file on your system. (doesn't help after the fact, but going forward...) At least then you could see which user/program did things to which files. I think even if a file is missing that you think should have been there you can do an audit search and see who deleted it. I've never tried it myself but that's how I understand it. I could be wrong. And it's not what you asked for, but for cleaning cruft out of distfiles i use eclean from app-portage/gentoolkit... works great. Whenever I'm running low on space I run it and it zaps a few gigs of unneeded stuff without deleting the distfiles of active packages. Paul
Re: [gentoo-user] Installing outside of Portage cruft removal
On Mon, January 26, 2009 18:35, Grant wrote: What do you guys think of this? Do you know of a good cruft removal script? Yep, there's quite good one in gentoo itself. Basically, you'll need to write a short config for it, consisting of lines like cruft name, cruft src uri and a few more lines if you'll need to pass some extra parameters to configure/make/install. It'll build the package in a sandbox, then transfer it to destination, memorizing every change it did and preventing collisions and config overwrites. Just put that config script into an ebuild file and use portage to build it - as simple as it gets ;) I suppose you and Jesus are right, but what about cruft removal? Are you saying Gentoo is 100% cruft-free? I've got a lot of junk in /etc and especially ~/.* No. It isn't 100% free. Emerge will only remove the stuff it installed. There's absolutely no way to guarantee that any file in /etc is not needed any longer. Besides that: 1.- YOU created those files, so you are the one that should keep the track of them 2.- They are not part of the package, emerge will only uninstall what it installed, nothing else, I would be very angry if a silly package manager starts deleting files I created by hand. 3.- you might want to install that package again, and you are probably not willing to reconfigure it again 4.- seriously, even three thousand of files in /etc are not a problem. They take a few bytes or several kb at most. You better look at /usr/src or the number of installed games and/or icon themes. In the rest of the three there shouldn't be too much cruft if you stick to portage and don't go installing things by hand around (if you do then you can't blame portage neither). Cruft removers base their actions on guesses. I never felt like those programs really worked at all. If you use one of them you have still to review the final list before removal (that or you are good at making backups, you know). So I don't know what the point is. I would be quicker to clean the tree myself using mc and some bash magic. -- Jesús Guerrero
Re: [gentoo-user] Installing outside of Portage cruft removal
I suppose you and Jesus are right, but what about cruft removal? Are you saying Gentoo is 100% cruft-free? I've got a lot of junk in /etc and especially ~/.* No it isn't, but this is very hard to automate cruft detection via scripts as you still have to decide yourself if a file is really needed or not. It is very easy to compare all the files on the filesystem with the list of files controlled by portage. But everything that is left over is not cruft, because there are files you put somewhere yourself or files that are not controlled by portage but are essential to the system. So you have to use some kind of ignorelist to exclude files that are not under portage control but needed. As you see it is still you who has to decide if a file is cruft or not. I have done something minimalistic that evolved over time and that fits my needs. I long refrained from attaching it here, but as this question comes up so often I think I will share it. I am not a programming guru so there might be bugs or other stuff done in a poor way so don't come here and complain if the script has killed your kitten. I will attach the cruft script written in perl and as an example the ignorelist I use for my system and the list of cruft files that remain as false positives. You have to customize the ignorelist yourself so it does a proper job on your system. I have tried to make the script user friendly but it surly isn't so you may have to tinker with it a bit. The script actually does not delete anything it just presents you a list of files that contains all files on the filesystem minus the files controlled by portage and minus the files you have ignored. There is also another cruft script that you may get from overlays but I don't remember where. If you search the archives you may find it as it has already been mentioned here. Regards, Daniel Thank you Daniel and Dale and everyone for their opinions regarding this. Adding a list of files tracked by portage to a list of files specified by me and reporting on the different sounds like a very useful thing to me. Daniel, can you remember anything else about that cruft script from an overlay? I can't seem to come up with it from Google. Writing an ebuild is best, but sometimes you just want to give a program a try without writing an ebuild (like everyone else running Linux does) and a scruft script enables you to do that without making a mess of your system. - Grant
Re: [gentoo-user] Installing outside of Portage cruft removal
I think if you enable auditing in the kernel and emerge sys-process/audit you can see the access history of any file on your system. (doesn't help after the fact, but going forward...) At least then you could see which user/program did things to which files. I think even if a file is missing that you think should have been there you can do an audit search and see who deleted it. I've never tried it myself but that's how I understand it. I could be wrong. That could be really handy if you could find out when was the last time a file was accessed. If you weren't sure that a file is cruft or not, you could examine that last access date. And it's not what you asked for, but for cleaning cruft out of distfiles i use eclean from app-portage/gentoolkit... works great. Whenever I'm running low on space I run it and it zaps a few gigs of unneeded stuff without deleting the distfiles of active packages. Yeah, eclean is great. - Grant
Re: [gentoo-user] Installing outside of Portage cruft removal
On Mon, January 26, 2009 21:17, Grant wrote: Writing an ebuild is best, but sometimes you just want to give a program a try without writing an ebuild (like everyone else running Linux does) and a scruft script enables you to do that without making a mess of your system. Not to be picky, it's just an idea but in that case, isn't it way easier to just ./configure --prefix=/some/dir/inside/yourhome or edit a makefile? -- Jesús Guerrero
Re: [gentoo-user] Installing outside of Portage cruft removal
Writing an ebuild is best, but sometimes you just want to give a program a try without writing an ebuild (like everyone else running Linux does) and a scruft script enables you to do that without making a mess of your system. Not to be picky, it's just an idea but in that case, isn't it way easier to just ./configure --prefix=/some/dir/inside/yourhome or edit a makefile? I have to say I know nothing about compiling or installing outside of portage. Does specifying a prefix like that work? You get a fully functional program with nothing installed outside of some/dir? - Grant
Re: [gentoo-user] Installing outside of Portage cruft removal
On Mon, Jan 26, 2009 at 2:30 PM, Grant emailgr...@gmail.com wrote: Writing an ebuild is best, but sometimes you just want to give a program a try without writing an ebuild (like everyone else running Linux does) and a scruft script enables you to do that without making a mess of your system. Not to be picky, it's just an idea but in that case, isn't it way easier to just ./configure --prefix=/some/dir/inside/yourhome or edit a makefile? I have to say I know nothing about compiling or installing outside of portage. Does specifying a prefix like that work? You get a fully functional program with nothing installed outside of some/dir? Yes, it's the normal way for people that don't use package managers. I almost always install into my home directory for programs that aren't in portage (or make my own ebuild if it is a simple one). Or depending on what program it is, create a user for it and run it under that user account so it can't touch anything else. Also, a lot of more simple programs don't even need to be installed. Just untar it, configure it, make it and run it from the directory in which the source resides. Paul
Re: [gentoo-user] Installing outside of Portage cruft removal
On Mon, Jan 26, 2009 at 2:44 PM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Mon, Jan 26, 2009 at 2:30 PM, Grant emailgr...@gmail.com wrote: Writing an ebuild is best, but sometimes you just want to give a program a try without writing an ebuild (like everyone else running Linux does) and a scruft script enables you to do that without making a mess of your system. Not to be picky, it's just an idea but in that case, isn't it way easier to just ./configure --prefix=/some/dir/inside/yourhome or edit a makefile? I have to say I know nothing about compiling or installing outside of portage. Does specifying a prefix like that work? You get a fully functional program with nothing installed outside of some/dir? Yes, it's the normal way for people that don't use package managers. I almost always install into my home directory for programs that aren't in portage (or make my own ebuild if it is a simple one). Or depending on what program it is, create a user for it and run it under that user account so it can't touch anything else. Also, a lot of more simple programs don't even need to be installed. Just untar it, configure it, make it and run it from the directory in which the source resides. Paul I should also say that installing that stuff to /usr/local tree is also normal.
Re: [gentoo-user] Installing outside of Portage cruft removal
Grant schrieb am 26.01.2009 21:17: Thank you Daniel and Dale and everyone for their opinions regarding this. Adding a list of files tracked by portage to a list of files specified by me and reporting on the different sounds like a very useful thing to me. Daniel, can you remember anything else about that cruft script from an overlay? I can't seem to come up with it from Google. hollow - app-admin/findcruft2 gentoo-taiwan - app-portage/findcruft Both overlays mentioned above are available via layman but I think findcruft2 is newer and currently maintained. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Installing outside of Portage cruft removal
On Mon, January 26, 2009 21:44, Paul Hartman wrote: On Mon, Jan 26, 2009 at 2:30 PM, Grant emailgr...@gmail.com wrote: Writing an ebuild is best, but sometimes you just want to give a program a try without writing an ebuild (like everyone else running Linux does) and a scruft script enables you to do that without making a mess of your system. Not to be picky, it's just an idea but in that case, isn't it way easier to just ./configure --prefix=/some/dir/inside/yourhome or edit a makefile? I have to say I know nothing about compiling or installing outside of portage. Does specifying a prefix like that work? You get a fully functional program with nothing installed outside of some/dir? Yes, it's the normal way for people that don't use package managers. I almost always install into my home directory for programs that aren't in portage (or make my own ebuild if it is a simple one). Or depending on what program it is, create a user for it and run it under that user account so it can't touch anything else. Yes. It's mostly that simple. Though sometimes in more complex programs you might need some extra setup (i.e. configure some variable so the program can find its path to the required libs or so). It really depends on the program, however if you open the readme or install file and take a look 99% of the times the procedure should be described there. Not all programs use the tipical make system, so you should always check the docs, and in any case save the source tree for further refference, or just to be able to make uninstall. Note that this is the cleanest method, and in some cases it's the only option (i.e. you don't have root access to the machine, so you have to build in your home dir). Also, a lot of more simple programs don't even need to be installed. Just untar it, configure it, make it and run it from the directory in which the source resides. This work for smaller programs very well. Just make and launch it. -- Jesús Guerrero
Re: [gentoo-user] Installing outside of Portage cruft removal
Thank you Daniel and Dale and everyone for their opinions regarding this. Adding a list of files tracked by portage to a list of files specified by me and reporting on the different sounds like a very useful thing to me. Daniel, can you remember anything else about that cruft script from an overlay? I can't seem to come up with it from Google. hollow - app-admin/findcruft2 gentoo-taiwan - app-portage/findcruft Both overlays mentioned above are available via layman but I think findcruft2 is newer and currently maintained. Thank you, I'll give findcruft2 a try. - Grant
Re: [gentoo-user] Installing outside of Portage cruft removal
Writing an ebuild is best, but sometimes you just want to give a program a try without writing an ebuild (like everyone else running Linux does) and a scruft script enables you to do that without making a mess of your system. Not to be picky, it's just an idea but in that case, isn't it way easier to just ./configure --prefix=/some/dir/inside/yourhome or edit a makefile? I have to say I know nothing about compiling or installing outside of portage. Does specifying a prefix like that work? You get a fully functional program with nothing installed outside of some/dir? Yes, it's the normal way for people that don't use package managers. I almost always install into my home directory for programs that aren't in portage (or make my own ebuild if it is a simple one). Or depending on what program it is, create a user for it and run it under that user account so it can't touch anything else. Yes. It's mostly that simple. Though sometimes in more complex programs you might need some extra setup (i.e. configure some variable so the program can find its path to the required libs or so). It really depends on the program, So for example, miro needs xine to play videos. If I ./configure miro with --prefix=/usr/local, it will install to /usr/local/miro or similar? Then I would need to point it to xine and possibly others since it wasn't configured like --prefix=/ ? Is all this done as root? however if you open the readme or install file and take a look 99% of the times the procedure should be described there. Not all programs use the tipical make system, so you should always check the docs, and in any case save the source tree for further refference, or just to be able to make uninstall. Couldn't I just uninstall with 'rm -rf /usr/local/miro' ? - Grant Note that this is the cleanest method, and in some cases it's the only option (i.e. you don't have root access to the machine, so you have to build in your home dir). Also, a lot of more simple programs don't even need to be installed. Just untar it, configure it, make it and run it from the directory in which the source resides. This work for smaller programs very well. Just make and launch it.
Re: [gentoo-user] Installing outside of Portage cruft removal
On Mon, 26 Jan 2009 22:57:13 +0500, Mike Kazantsev wrote: AFAIK portage won't remove any changed (by hand) files in CONFIG_PROTECT paths, Portage won't remove any files in CONFIG_PROTECTed paths,changed ornot. It also won't remove any files that have been changed since installation, wherever they were installed. -- Neil Bothwick When puns are outlawed only outlaws will have puns. signature.asc Description: PGP signature
