there are two completely unrelated executables with the same name "runscript". One belonging to "sys-apps/baselayout", the other belonging to "net-dialup/minicom". Reproducible: Always Steps to Reproduce: 1. 2. 3.
considering how tightly /sbin/runscript is integrated into Gentoo (every init.d script has its path hardcoded), i dont think there is much we can do about this issue most of the time, a user should not be executing /sbin/runscript, and since default Gentoo profiles put /usr/bin before /sbin (and /sbin isnt even in the normal PATH for non-root users), i doubt many people notice this issue
I could solve it in minicom by changing default script program to "/usr/bin/runscript". thoughts?
this was not meant to be a true complaint, since i never had any problems regarding this. i just found this to be an untidyness that might be considered resolve-worthy by others too. i would be perfectly alright with it as it is.
yes, to be safe, all of minicom should use runscript by its full path ...
solved in minicom-2.1-r2, that sets the default script to /usr/bin/runscript.
Hate to bump an old bug… but attempting to merge this on a system that uses the new (still experimental) merged-usr profiles (default/linux/amd64/23.0/hardened)… it is still a problem: From the build log: * checking 14 files for package collisions * This package will overwrite one or more files that may belong to other * packages (see list below). You can use a command such as `portageq * owners / <filename>` to identify the installed package that owns a * file. If portageq reports that only one package owns a file then do * NOT file a bug report. A bug report is only useful if it identifies at * least two or more packages that are known to install the same file(s). * If a collision occurs and you can not explain where the file came from * then you should simply ignore the collision since there is not enough * information to determine if a real problem exists. Please do NOT file * a bug report at https://bugs.gentoo.org/ unless you report exactly * which two packages install the same file(s). See * https://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how * to solve the problem. And once again, please do NOT file a bug report * unless you have completely understood the above message. * * Detected file collision(s): * * /usr/bin/runscript * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * sys-apps/openrc-0.48:0::gentoo * /usr/sbin/runscript * * Package 'net-dialup/minicom-2.8-r2' NOT merged due to file collisions. * If necessary, refer to your elog messages for the whole content of the * above message. Not quite sure why a file installed in /usr/bin clashes with an identical file in /usr/sbin. collision-protect seems to be a bit overzealous.
On merged-use, /usr/bin and /usr/shin are the same path, so the files collide.
Have just spent a few minutes checking the state of things out of curiosity. The transition to openrc-run (and /sbin/rc -> /sbin/openrc) happened a whole decade ago[1]. There's no need for the openrc ebuild to install /sbin/runscript or /sbin/rc any more - it's safe to delete runscript in particular because the only references to it in ::gentoo are ancient patches to replace its shebang with openrc-run. On a side note, *most* of openrc's binaries are redundant - its build system compiles about 3-4 dozen near-identical programs that differ only in argv[0] and ELF header bytes. But that's neither here nor there. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684396
Removed on master. https://github.com/OpenRC/openrc/commit/88e5d98d051c99cded4c9bdde98505b281bb3e80
*** Bug 921285 has been marked as a duplicate of this bug. ***
Should be fixed in openrc-0.52.
