| 1 |
On 03/09/2017 06:16 PM, William L. Thomson Jr. wrote: |
| 2 |
> |
| 3 |
> Case in point dev-db/firebird use to have a line like |
| 4 |
> |
| 5 |
> rm -rf "${S}"/extern/{btyacc,editline,icu} || die |
| 6 |
> |
| 7 |
> But if you look at current ebuild it is now |
| 8 |
> |
| 9 |
> rm -r "${S}"/extern/{btyacc,editline,icu} || die |
| 10 |
> |
| 11 |
> The force option/argument was dropped. Why? Seems it could have remained. |
| 12 |
> Which is why I commented, as I am pretty sure that has been said to me before. |
| 13 |
|
| 14 |
Whether "-f" is appropriate or not depends on the context. |
| 15 |
|
| 16 |
With firebird, you expect all of those directories to exist, and you |
| 17 |
want to be notified (so that you can update the ebuild) if one of them |
| 18 |
isn't there. If upstream unbundles those three libraries and you're |
| 19 |
doing "rm -rf", then you'll never notice, and that (now pointless) line |
| 20 |
of code will stay there forever. |
| 21 |
|
| 22 |
In the golang-vcs eclass, you truly don't know that the directory will |
| 23 |
exist, so "-f" is needed to avoid a "no such directory" error. |
| 24 |
|
| 25 |
|
| 26 |
> Essentially do not use -f with || die or something to that effect. Maybe for |
| 27 |
> different reasoning. Still one of those things I never liked. Do it this way, |
| 28 |
> for this reason, that is not documented. Others may digress and leads to |
| 29 |
> confusion. |
| 30 |
|
| 31 |
There's an easy rule: always use "|| die" on commands that don't die |
| 32 |
themselves. It's always better to fail as soon as something unexpected |
| 33 |
happens. Otherwise it's probably going to fail later anyway, and you'll |
| 34 |
waste a whole lot of time trying to figure out why it *really* failed. |
| 35 |
|
| 36 |
There are exceptions to the rule, but it should be really obvious when |
| 37 |
you hit one, like if you have a test suite that always returns 1. |
Archives