installpkg -warn is broken
in [Slackware]
|
From: Eef Hartman on 8 Apr 2008 11:16 ciol <ciol13(a)gmail.com> wrote: > - Why in doinst.sh from ktorrent, there is: > ( cd usr/lib ; rm -rf libktorrent.so ) > ( cd usr/lib ; ln -sf libktorrent-2.2.4.so libktorrent.so ) > > ln -sf is not enough? ln -sf will do the job if "libktorrent.so" is a NORMAL file or already a symbolic link (which it is meant to be), but not if i.e. "libktorrent.so" is a subdir (because the -f in ln only does what rm -f would do, but a subdir will need -rf). That is also why the extra warning from installpkg -warn, because rm -rf is VERY destructive, you really must be sure you want to do that. -- ******************************************************************** ** Eef Hartman, Delft University of Technology, dept. EWI/TW ** ** e-mail: E.J.M.Hartman(a)math.tudelft.nl, fax: +31-15-278 7295 ** ** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands ** ********************************************************************
From: Eef Hartman on 8 Apr 2008 11:34 Joseph H. Rosevear <joe(a)airlink9.hopto.org> wrote: > I've never bumped into a limit because I had too many processes > running. I have however crashed xargs because of too much environment > space being used. In fact, I regularly use a modified xargs compiled > to allow more environment space. I guess I hog up a lot of space. You're confusing two things: - environment space is where 'export'ed variables go, like the PATH - commandline space is where all the arguments AFTER the command, i.e. echo `man bash` the "man bash" part are stored to PASS them from the shell, which is reading the commandline, to the application (in this case "echo"), who wants to DO something with those args. The "xargs" command is one of the ways to get around the latter limit, for instance (dir with a million .c files): ls *.c <commandline too long> (or a message like that) find . -maxdepth 1 -name \*.c | xargs ls (the find is just there to get a list of all those .c files). Of course in this SIMPLE case, just "ls | grep '\.c$'" will work much better (ls without args doesn't HAVE arguments, so will list the whole directory, the grep gets the ones that end on .c). PS: the " is just to show the commandline, the ' chars are essential! -- ******************************************************************** ** Eef Hartman, Delft University of Technology, dept. EWI/TW ** ** e-mail: E.J.M.Hartman(a)math.tudelft.nl, fax: +31-15-278 7295 ** ** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands ** ********************************************************************
From: Eef Hartman on 8 Apr 2008 11:42 Martijn Dekker <martijn(a)inlv.demon.nl> wrote: > I believe this is the intended behavior. I have never found that > option useful. The difference with a plain tar, as has been proposed furtheron in this chain, is that "installpkg -warn" also checks the "doinst.sh" for symbolic links that will be created and may overwrite existing files/subdirs, etc. (as doinst.sh does a rm -rf first, existing files/subdirs with the same name as a "to be created" symbolic link will be removed totally). But it would have been nicer if it checked for existance OF those files/dirs etc. first.... -- ******************************************************************** ** Eef Hartman, Delft University of Technology, dept. EWI/TW ** ** e-mail: E.J.M.Hartman(a)math.tudelft.nl, fax: +31-15-278 7295 ** ** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands ** ********************************************************************
From: Joseph Rosevear on 9 Apr 2008 15:16 Eef Hartman <E.J.M.Hartman(a)math.tudelft.nl> wrote: > Joseph H. Rosevear <joe(a)airlink9.hopto.org> wrote: > > I've never bumped into a limit because I had too many processes > > running. I have however crashed xargs because of too much environment > > space being used. In fact, I regularly use a modified xargs compiled > > to allow more environment space. I guess I hog up a lot of space. > You're confusing two things: [snip] Eef, I may not completely understand (some confusion possible), but I'm pretty sure about two things: xargs will crash when the environment is too large this can be solved by changing and recompiling the source for xargs Here is a note about the problem that I put in my SAM Kernel documentation (on Sourceforge): vvv SAM puts a lot of stuff in the environment. In particular, it exports a lot of variables and functions. This is why I sometimes got an error message which said "xargs: environment is too large for exec". The solution I found was to change xargs and recompile it, then replace the original xargs with the corrected one. Here's the piece of code I changed, before and after: Before: if (arg_max > 20 * 1024) arg_max = 20 * 1024; After: /* JHR 050813 I commented out and changed the two lines below */ /*if (arg_max > 20 * 1024) arg_max = 20 * 1024; */ if (arg_max > 40 * 1024) arg_max = 40 * 1024; I learned that this was the needed fix by what I found when searching in Google Groups "www.groups.google.com" on the quoted error message. After doubling the limit (from 20K to 40K) I've had no trouble...yet. ^^^ Try Googling "xargs: environment is too large for exec" and use the quotes. You'll find some "direct" hits on the issue and some other hits that tend to cloud the issue. This one is perhaps a "direct" hit: http://listmgr.cv.nrao.edu/pipermail/chuug/2003-July/003080.html and it contains a link to this possibly pertinent information: http://lists.gnu.org/archive/html/bug-findutils/2002-09/msg00004.html This hit may be pertinent: http://www.gnu.org/software/findutils/manual/html_node/find_html/Error-Messages-From-xargs.html The above says: vvv environment is too large for exec This message means that you have so many environment variables set (or such large values for them) that there is no room within the system-imposed limits on program command line argument length to invoke any program. This is an unlikely situation and is more likely result of an attempt to test the limits of xargs, or break it. Please try unsetting some environment variables, or exiting the current shell. You can also use xargs --show-limits to understand the relevant sizes. ^^^ -Joe
From: Kees Theunissen on 9 Apr 2008 16:29
Joseph Rosevear wrote: > Eef Hartman <E.J.M.Hartman(a)math.tudelft.nl> wrote: > >>Joseph H. Rosevear <joe(a)airlink9.hopto.org> wrote: >> >>>I've never bumped into a limit because I had too many processes >>>running. I have however crashed xargs because of too much environment >>>space being used. In fact, I regularly use a modified xargs compiled >>>to allow more environment space. I guess I hog up a lot of space. > > >>You're confusing two things: > > > [snip] > > Eef, > > I may not completely understand (some confusion possible), but I'm > pretty sure about two things: > > xargs will crash when the environment is too large > this can be solved by changing and recompiling the source for xargs Linux supports a maximum size of 128K of the arguments plus environment together for exec(). See /usr/include/linux/limits.h: ... #define ARG_MAX 131072 /* # bytes of args + environ for exec() */ ... But xargs chooses to build smaller command lines (max 20K _including_ the environment) when exec()-ing a program. That is probably to make sure that the childs have a reasonable amount of free space left in their environments. Regards, Kees. -- Kees Theunissen. |