To my surprise `doins' doesn't check for the existence of the files being passed. I wonder, because I had to experience the effects of this fact yesterday (cf. Bug #86242[*]). Shouldn't `doins' /at least/ complain with a Warning, if not abort the emerge process? Imho, a warning is a minimun, as you can see for yourself: >>> Install erc-5.0.2 into /var/tmp/portage/erc-5.0.2/image/ category app-emacs /var/tmp/portage/erc-5.0.2/work/erc-5.0.2 /var/tmp/portage/erc-5.0.2/work/erc-5.0.2 cp: cannot stat `/usr/portage/app-emacs/erc/files/5.0.2/50erc-gentoo.el': No such file or directory sed: can't read /var/tmp/portage/erc-5.0.2/temp/50erc-gentoo.el: No such file or directory install: cannot stat `/var/tmp/portage/erc-5.0.2/temp/50erc-gentoo.el': No such file or directory During an `emerge --update world' those messages are generally missed, and grepping for a warning would have made an investigation easier. Yet, I think, optimally `doins' would abort the build unless some magic flag in `INSOPTION' is set or some parameter is passed (similiarly to what `-p' does to `mkdir'). This way, an author of an ebuild can deliberately take into consideration that the `doins' won't possibly install some of the files he passes. The default is the defensive case: Assume the worst and hence think of it as an internal error and abort. For the case that I'm just mistaken, I'd like to receive enlightment, please. :-) [*] http://bugs.gentoo.org/show_bug.cgi?id=86242 Reproducible: Always Steps to Reproduce: 1. 2. 3.
the ebuild is wrong, it should have called `doins ... || die` doins is an external script, it cannot cause portage to abort by itself
> the ebuild is wrong, it should have called `doins ... || die` (It was an eclass.) However, it's a bit unfortunate that you concentrated on the specific example solely and didn't dive into my more general concern. However, I'll interpret you as having stated the following: "All ebuilds which use
> the ebuild is wrong, it should have called `doins ... || die` (It was an eclass.) However, it's a bit unfortunate that you concentrated on the specific example solely and didn't dive into my more general concern. However, I'll interpret you as having stated the following: "All ebuilds which use ´doins' to install (important) files without caring about error detection themselves, are wrong." This clearly is a policy. But do you think this is a good default policy? Let's look at some numbers: In my portage tree, there are about 7200 occurences of `doins' in ebuild resp. eclass files, yet only about 650 of these who would potentially call `die', too; this means the remaining chunk is as large as 6650. These 6650 occurences of `doins' without a `die' correspond to about 3200 different ebuilds which are possibly wrong by your definition. These 3200 ebuilds are the ebuilds of about 1550 different pkgs. Looking through the list of these occurences make me suspicious that most of those calls to `doins' alone should actually invoke `die' on failure. And that's not all that strange considering that `doins' is mostly just used as its semantics suggest, ie. to install a couple of files. So, I think, one can actually assume that quite a huge proportion of the 1550 pkgs are, well, worthy of improvement---to name it euphemistically. Well. For the case that you disagree with the above, or for the case that you principially agree, but a proper fix might have to wait, because it would potentially break existings ebuilds, so that it's only dared to introduce this when another scabrous (compability-wise) step is about to be performed --- a (temporary) improvement would be to emit warnings if emerge was invoked with VERBOSE or DEBUG (or similiar) flags. In the meanwhile, I'll do a bug request concerning the missing ``|| die' in the eclass file that was responsible for Bug #86242. --tcr.
you missed one of the most important aspects of my comment ... doins is an external binary and thus cannot trigger 'die' ;)
