app-shells/bash -r-xr-xr-x /usr/bin/bashbug See the tracker for more complete explanation of issues with files not writeable by owner.
i don't see a problem here, and no specific issues have been cited here
Then how about you read the explanation on the tracker? Or are you so special that you require everything to be handed immediately over to you on a golden plate? In any case, since this executable is installed differently than almost any other executable on the system, it is *your* responsibility to provide a good reason for doing so.
(In reply to Michał Górny from comment #2) keep your personal attack garbage to yourself. here's a link to the CoC: https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct i did read the tracker and it contains no specific issues, just vague references with no citations or concrete examples. you still haven't cited any. claiming "it's different' is not a concern, nor is it a requirement for compliance when there is no policy (nor should there be one). so until you actually quote a real problem, there's nothing to be done here.
for fun, i looked at the bash-2.05b sources and the install mode of this script is the same there. that means Gentoo has been installing this file this way for more than 14 years and no one, across any of the myriad of system configs, has reported a problem. you still haven't reported one. so the burden is entirely on you to justify why 14+ years of no bugs suddenly necessitates a change.
Yes, it is unlikely that bashbug is broken in any specific way on the systems you care about. It's a little inconvenient on other systems but people can work that around easily, so they don't bother filing bugs. Nevertheless, that doesn't explain why you couldn't improve things. The time you wasted so far is much more than needed to fix this. The check catches this as a false positive, most likely. Nevertheless, I see no reason to add exception for a file that has no reason to be special when the same check can also catch valid issues. Again, fixing this is around 30 seconds of thinking, 15 seconds of altering the ebuild and time needed for test rebuild.
(In reply to Michał Górny from comment #5) you still have cited no specific examples. vague references like "it's broken on systems i don't care about" is not sufficient. considering people file bugs for some of the most trivial things, also claiming people are working around it and not filing bugs is pretty weak. what you're asking for is to add & carry indefinitely dead code in ebuilds (and perhaps patches to upstream files) with 0 justification. until you provide something, it's a lot easier to make no changes and have to maintain 0 baggage. stop wasting time and cite concrete problems. if you don't have any, then admit it, and move on.
Concrete problems: vim /usr/bin/bashbug opens the file readonly. For no good reason. When bash is installed as unprivileged user (e.g. permission-reduced prefix): echo foo > $eprefix/usr/bin/bashbug fails because the owner can't write to the file. rm $eprefix/usr/bin/bashbug asks for unnecessary confirmation. Don't you think it's silly to have more restrictions on a random bash script than on bash itself?
(In reply to Michał Górny from comment #7) i don't see any of those as problems. what else ?
