From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id F1D8013877A for ; Tue, 15 Jul 2014 12:13:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EB3B6E09A5; Tue, 15 Jul 2014 12:13:54 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DF680E08A2 for ; Tue, 15 Jul 2014 12:13:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 38F5233F649 for ; Tue, 15 Jul 2014 12:13:53 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5.5 tests=[AWL=-1.157, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc0ZpKxWdZXq for ; Tue, 15 Jul 2014 12:13:47 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 6863033FB2C for ; Tue, 15 Jul 2014 12:13:46 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1X71c7-0005s3-DD for gentoo-dev@gentoo.org; Tue, 15 Jul 2014 14:13:43 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Jul 2014 14:13:43 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Jul 2014 14:13:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: find ${D} -delete in src_install() ? Date: Tue, 15 Jul 2014 12:13:28 +0000 (UTC) Message-ID: References: <20140715100054.21131.qmail@stuge.se> <53C4FD42.3040704@gentoo.org> <20140715102431.22988.qmail@stuge.se> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT d447f7c /m/p/portage/src/egit-src/pan2) X-Archives-Salt: e83d0686-0377-4d55-8302-0149d0107df2 X-Archives-Hash: 2e23891a2f2475096aa66199c137055c Peter Stuge posted on Tue, 15 Jul 2014 12:24:31 +0200 as excerpted: > If $D was in my root I sure would not want ebuilds to randomly delete > files only based on filename. FWIW, I was looking at some other ebuild the other day and saw something similar, that threw me for a loop for a moment... but then I remembered that $D was NOT root, but rather, the pre-qmerge image's root. So you're no the only one to come across something like that and have a lapse. It's just weird to see an rm like that, and the sysadmin instincts kick in! OTOH, I had a brown-paper-bag incident with one of my own scripts doing something similar a couple years ago. The problem was a typo in the varname, so the var I set wasn't used and the var that was used ended up empty! And I made the mistake of running it as root before proper testing! Oops!!!111! Two lessons learned: 1) Test such scripts as non-root first. 2) When setting up scripted rms and the like, do something like [[ -d $var ]] && rm ... . That way, if there's a typo or the var ends up empty for whatever reason, it doesn't do the rm at all! The find -type f -name xxx -exec rm avoids the problem with a different technique, checking both name and type (normal file, not a directory!), thus strictly limiting the damage even if somehow "${D}" ended up empty and it did go off the rails. The embarrassing bit for me was that I was in the middle of bisecting a pre-release kernel bug at the time, and kernel devs were waiting on the results in ordered to get a fix in before release when it happened and I had to drop that for the moment and do a working system restore from backup! Brown paper bag time, indeed! =8^0 But I've seen it explained as a mistake every admin must make at some point, and if it hasn't happened yet, that simply means the mistake is still waiting in your future, so keep those backups ready! Of course one you've done it, those alarm bells are primed and ready, which is why they go off so easily reading things like the OP's ebuild excerpt. But that's actually a GOOD thing! =:^) Meanwhile for portage, sandbox and userpriv during at least part of the merge do help, but obviously they can't be used during the entire merge. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman