From bug 184432: ------- Comment #1 From Paul Bredbury 2007-07-06 18:15:24 0000 [reply] ------- The Gentoo devs forgot to populate /usr/portage/x11-drivers/nvidia-drivers/files/ with nvidia-settings.{png,desktop} doicon and domenu in /usr/portage/eclass/eutils.eclass are far too fault-tolerant, meaning that the "|| die" sanity protections in the ebuild are useless. The BASH code should *not* be skipping over these errors.
Created attachment 124136 [details, diff] eutils-domenu-doicon.patch
Good, but I'd go a step further. The subroutine should not be going off and doing its own thing if the target is a *directory* rather than a file - this should be another error. Ebuilds which want to operate on a directory could just as easily put "doicon mydir/* || die".
Created attachment 124151 [details, diff] eutils.eclass.patch This should make doicon and domenu flag an error on missing files. I used ((ret++)) for consistency, but I do think the functions should just exit 1 on the first error instead of trying all the files. kk this would break the tree, but i thought the point was to die if there's any error? It's not like the calling ebuild will know which file failed is it? Thanks to peper for help :-)
Created attachment 124154 [details, diff] eutils.eclass.patch Doh! Really sorry for spam, put lines in wrong place. > The subroutine should not be going off and doing its own thing if the target > is a *directory* rather than a file - this should be another error. Ebuilds > which want to operate on a directory could just as easily put "doicon > mydir/* || die" Yeah but the existing functions provide the dir option, so it has to be kept for consistency. I tried to make the patch as light as possible for that reason. Anyhow good luck with it.
> Yeah but the existing functions provide the dir option That's a stupid bit of misguided "helpfulness", just as "an error occurred? Oh well, let's just continue onwards anyway" is helpful as the BASH default. It's stupid. How on Earth can you write *reliable* programs which use such subroutines? It's a lottery as to whether they do the desired thing, or don't do it.
if you want to remove functionality, you cannot just do it without fixing the tree first get the tree fixed and then you can talk about removing the dir handling
(In reply to comment #5) > > Yeah but the existing functions provide the dir option > > That's a stupid bit of misguided "helpfulness", just as "an error occurred? Oh > well, let's just continue onwards anyway" is helpful as the BASH default. It's > stupid. How on Earth can you write *reliable* programs which use such > subroutines? It's a lottery as to whether they do the desired thing, or don't > do it. > I don't think there's anything at all wrong with providing a directory handling option; I agree that not erroring out on the first problem is foolish (as I outlined above.) If that is allowed, I'll happily provide a patch to do so. I simply do not know whether any existing ebuilds use that functionality. (To my mind they should just be doing, say, doicon blah || die but I have only written a few ebuilds, so I am not an expert.) (And please, don't bring bash into it. If a coder doesn't check for errors, that's their fault.. you might as well slag C syscalls off for the same reason.)
