With CONFIG_PROTECT="... /usr/lib/distcc/bin" Before reinstalling sys-devel/distcc: elmer /usr/lib/distcc/bin # ls -l c++ -> hppa2.0-unknown-linux-gnu cc -> hppa2.0-unknown-linux-gnu g++ -> hppa2.0-unknown-linux-gnu gcc -> hppa2.0-unknown-linux-gnu hppa2.0-unknown-linux-gnu hppa2.0-unknown-linux-gnu-c++ -> /usr/bin/distcc hppa2.0-unknown-linux-gnu-g++ -> /usr/bin/distcc hppa2.0-unknown-linux-gnu-gcc -> /usr/bin/distcc After reinstalling sys-devel/distcc: elmer /usr/lib/distcc/bin # ls -l c++ -> /usr/bin/distcc cc -> /usr/bin/distcc g++ -> /usr/bin/distcc gcc -> /usr/bin/distcc hppa2.0-unknown-linux-gnu hppa2.0-unknown-linux-gnu-c++ -> /usr/bin/distcc hppa2.0-unknown-linux-gnu-g++ -> /usr/bin/distcc hppa2.0-unknown-linux-gnu-gcc -> /usr/bin/distcc I need to run for i in c* g*; do rm -v $i && ln -sv hppa2.0-unknown-linux-gnu $i; done after every reinstall (to make the symlinks point to a script that auto-corrects [cg]* --> hppa2.0-unknown-linux-gnu-[cg]* and issues a warning on stderr. I don't see why these symlinks are not protected. Apparently similar bugs were fixed in sys-apps/portage in the past. bug #54053 cri High dev-portage@gentoo.org RESO FIXE Linu CONFIG_PROTECT does not work for symlinks bug #151502 nor High dev-portage@gentoo.org RESO FIXE Linu CONFIG_PROTECT and symlinks
I would also like to see this fixed. sys-apps/systemd installs a number of symlinks in /etc/systemd by default, and these may manipulated by the sysadmin to adjust their system startup. However, any changes get clobbered when you upgrade systemd. We currently work around this by removing the symlinks in src_install and forcing the user to create them manually via 'systemctl enable'.
I've started working on this in the following branch: https://github.com/zmedico/portage/tree/bug_485598 Most of the changes to the merge code are complete. I haven't started on etc-update/dispatch-conf support yet.
The etc-update behavior for merging a regular file where there's an existing symlink is update the regular file that the symlink points to (see bug #330221). Please comment if you have a problem with that. Otherwise, I'll assume that this behavior is acceptable.
(In reply to Zac Medico from comment #3) > The etc-update behavior for merging a regular file where there's an existing > symlink is update the regular file that the symlink points to (see bug > #330221). Please comment if you have a problem with that. Otherwise, I'll > assume that this behavior is acceptable. That should be fine as long as CONFIG_PROTECT enables me to get rid of the updates. :) Case in point is /usr/lib/distcc/bin, where I replace the usual symlinks to /usr/bin/distcc with symlinks to a script matching the canonical toolchain tuple: /usr/lib/distcc/bin/c++ -> x86_64-pc-linux-gnu (and so on). The /usr/lib/distcc/bin/x86_64-pc-linux-gnu script is mine, and any updates I could just throw away again. The only problem I see is that it might then offer me a comparison between an executable binary and a script. :)
(In reply to Zac Medico from comment #2) > I've started working on this in the following branch: > > https://github.com/zmedico/portage/tree/bug_485598 It's basically complete now. There are lots of changes, and I need review it all. Then I'll post a patch and ask for testers.
I've posted patches for review here: http://thread.gmane.org/gmane.linux.gentoo.portage.devel/4687
This is in git now: https://github.com/gentoo/portage/commit/02417188225758b1822d176abd8902a92300a371 https://github.com/gentoo/portage/commit/f17448317166bfac42dc279b8795cd581c189582 https://github.com/gentoo/portage/commit/6659c00a580254f68460608b4cdc5df8e057d17c
This is fixed in 2.2.15.
