[gentoo-dev] find ${D} -delete in src_install() ?

[gentoo-dev] find ${D} -delete in src_install() ?

[Peter Stuge]

I came across this in sys-power/pm-utils-1.4.1-r2.ebuild src_install():

# NetworkManager 0.8.2 is handling suspend/resume on it's own with UPower
find "${D}" -type f -name 55NetworkManager -exec rm -f '{}' +

This seems baroquely reckless, but it has been like that since 2010
with one revbump and a bunch of stabilizations, so maybe it's fine?

Is it really acceptable for an ebuild to delete all files in $D
which have a particular name?


//Peter

Re: [gentoo-dev] find ${D} -delete in src_install() ?

[Samuli Suominen]

On 15/07/14 13:00, Peter Stuge wrote:
> I came across this in sys-power/pm-utils-1.4.1-r2.ebuild src_install():
>
> # NetworkManager 0.8.2 is handling suspend/resume on it's own with UPower
> find "${D}" -type f -name 55NetworkManager -exec rm -f '{}' +
>
> This seems baroquely reckless, but it has been like that since 2010
> with one revbump and a bunch of stabilizations, so maybe it's fine?

I don't see anything reckless about it.

> Is it really acceptable for an ebuild to delete all files in $D
> which have a particular name?
>
>
> //Peter
>

Of course, why wouldn't it be? $D is the image directory of the package
before it's merged to
actual filesystem, and even if it weren't, it specifies -name as well,
so it's double-safe

Re: [gentoo-dev] find ${D} -delete in src_install() ?

[Peter Stuge]

Samuli Suominen wrote:
> > Is it really acceptable for an ebuild to delete all files in $D
> > which have a particular name?
> 
> Of course, why wouldn't it be? $D is the image directory of the
> package before it's merged to actual filesystem,

Ah yes! Of course - no problem!


> and even if it weren't, it specifies -name as well, so it's double-safe

If $D was in my root I sure would not want ebuilds to randomly delete
files only based on filename.


Thanks for the explanation!

//Peter

[gentoo-dev] Re: find ${D} -delete in src_install() ?

[Duncan]

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