1 |
Peter Stuge posted on Tue, 15 Jul 2014 12:24:31 +0200 as excerpted: |
2 |
|
3 |
> If $D was in my root I sure would not want ebuilds to randomly delete |
4 |
> files only based on filename. |
5 |
|
6 |
FWIW, I was looking at some other ebuild the other day and saw something |
7 |
similar, that threw me for a loop for a moment... but then I remembered |
8 |
that $D was NOT root, but rather, the pre-qmerge image's root. |
9 |
|
10 |
So you're no the only one to come across something like that and have a |
11 |
lapse. It's just weird to see an rm like that, and the sysadmin |
12 |
instincts kick in! |
13 |
|
14 |
OTOH, I had a brown-paper-bag incident with one of my own scripts doing |
15 |
something similar a couple years ago. The problem was a typo in the |
16 |
varname, so the var I set wasn't used and the var that was used ended up |
17 |
empty! And I made the mistake of running it as root before proper |
18 |
testing! Oops!!!111! |
19 |
|
20 |
Two lessons learned: |
21 |
|
22 |
1) Test such scripts as non-root first. |
23 |
|
24 |
2) When setting up scripted rms and the like, do something like |
25 |
[[ -d $var ]] && rm ... . That way, if there's a typo or the var ends up |
26 |
empty for whatever reason, it doesn't do the rm at all! |
27 |
|
28 |
The find -type f -name xxx -exec rm avoids the problem with a different |
29 |
technique, checking both name and type (normal file, not a directory!), |
30 |
thus strictly limiting the damage even if somehow "${D}" ended up empty |
31 |
and it did go off the rails. |
32 |
|
33 |
The embarrassing bit for me was that I was in the middle of bisecting a |
34 |
pre-release kernel bug at the time, and kernel devs were waiting on the |
35 |
results in ordered to get a fix in before release when it happened and I |
36 |
had to drop that for the moment and do a working system restore from |
37 |
backup! Brown paper bag time, indeed! =8^0 |
38 |
|
39 |
But I've seen it explained as a mistake every admin must make at some |
40 |
point, and if it hasn't happened yet, that simply means the mistake is |
41 |
still waiting in your future, so keep those backups ready! |
42 |
|
43 |
Of course one you've done it, those alarm bells are primed and ready, |
44 |
which is why they go off so easily reading things like the OP's ebuild |
45 |
excerpt. But that's actually a GOOD thing! =:^) |
46 |
|
47 |
Meanwhile for portage, sandbox and userpriv during at least part of the |
48 |
merge do help, but obviously they can't be used during the entire merge. |
49 |
|
50 |
-- |
51 |
Duncan - List replies preferred. No HTML msgs. |
52 |
"Every nonfree program has a lord, a master -- |
53 |
and if you use the program, he is your master." Richard Stallman |