When I accidently ran etc-update as a non-root user, it told me that there was a new fstab version available. I told it to delete the update, however it obviously did not have the nessesary permissions, so the delete failed, returning me to differences. These differences cover the error message, since they are now paged by default. It would be nice if etc-update as non-root was noticibly different from the root or at least a failure generated some kind of obvious visual alert/explanation. Reproducible: Always Steps to Reproduce: 1. Install new package with files in CONFIG_PROTECT 2. Run `etc-update` as an unprivileged user 3. Select update number 4. Push 'q' to exit pager showing differences 5. Choose 2 ( Delete update, keeping original as is ) 6. Say 'y' to "remove write-protected regular file" prompt Actual Results: I am again shown the differences between the files in the pager ( as though I had just completed step (2) above or had selected '4' ( Show differences again ) at step (5) above. It does show "rm: cannot remove `/etc/._cfg0000_fstab': Permission denied" ( output from the `rm -i` command, but I personally didn't notice it until I started looking rather closely and it is frequently pushed offscreen by the differences. Expected Results: Refused to let my run etc-update initially, showing a message such as the "emerge: root access required." that emerge shows when it's not at the correct permission level for installing. This happens with "1) Replace original with update" as well, as would be expected. If you do not wish to prevent non-root users from running it, ( perhaps so that as non-privileged it works as a --pretend, ) it would be nice to only show the differences. ( In other words not show the keep original, overwrite with new copy, interactive merge menu at all ). Another option would be to handle the error more overtly, perhaps with a failure menu ( an option in this menu to automatically run `sudo etc-update` if the sudo executable is available would be nice for failures caused by too-low permissions ). Portage 2.0.51-r2 (default-x86-2004.2, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.8-gentoo-r10 i686) ================================================================= System uname: 2.6.8-gentoo-r10 i686 AMD Athlon(tm) XP 2400+ Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=athlon-xp -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu"
or maybe have etc-update refuse to run if user isnt root ? ;)
SpanKY: That's what I posted under "Expected Results". I then thought some more, and figured out what I'd like if people decided they didn't like it just failing, for some reason. Just failing on insufficient permissions seems like a logical, good, and easy solution to me!
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
Adding a patch.
Created attachment 76588 [details, diff] Adds a check for UID 0 This needs to be tested wrt sudo and etc-update.
*** Bug 131754 has been marked as a duplicate of this bug. ***
In r3928
This has been released in 2.1.1_pre3-r2.
