Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: find ${D} -delete in src_install() ?
Date: Tue, 15 Jul 2014 12:13:59
Message-Id: pan$cdb47$686ec0a8$dc55844c$618be8b9@cox.net
In Reply to: Re: [gentoo-dev] find ${D} -delete in src_install() ? by Peter Stuge
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