I was trying to use the GUI installer in 2006.0 and run int this problem, so I decided to report it. The problem is that I selected vim as editor and fcron as cron daemon, however during install fcron was installed before vim and gave the following error: ... checking for sh... /bin/bash checking editor... configure: error: File /usr/bin/vim is not an executable file ... Not sure if fcron has to be hacked to not check during install, or it should be DEPENDing on virtual/editor, or the installer has to be changed to install editor before cron...
That's an interesting problem. I don't think anyone has ever actually tried changing the editor (or they did and vixie-cron doesn't check for it).
Yeah, and I am not sure if the installer is the component to be fixed. My first reaction was to add DEPEND on virtual/editor to fcron, but it already had it in the ebuild. So the question is more with the order of installing, and what satisfies virtual/editor at the time when cron daemon is emerged? Did nano slip in somewhere unnoticed again?
The problem is that virtual/editor is already satisfied by nano from the stage tarball. Honestly, the siplest method would probably be to not change EDITOR in rc.conf (or anywhere else) until after packages are copied/installed.
Moving to Release Media/Installer.
this isn't just during the installer phase. I ran into this problem when upgrading from 2.0.2 to 3.0.1 and I use nano as my editor
Reassigning as this really isn't a problem with the installer. This can easily happen in a "manual" install.
*** Bug 142379 has been marked as a duplicate of this bug. ***
Let me clarify some things: If you run configure without an explicit --with-editor=, it takes the value of the environment variable EDITOR. if this is not an absolute path, it looks for 'vi' in PATH. If it cannot find 'vi' in PATH, it bails out like this: --8<-- checking for vi... no configure: error: Cannot determine path to vi: try option --with-editor=PATH --8<-- So, we *must* make sure configure will get a working editor. I have tried both EDITOR=vim and EDITOR=/usr/bin/vim, both work fine with the ebuild. So, I don't really see a problem here, as EDITOR should be set in /etc/rc.conf.
OK, let me restate what happened and probably how can this be reproduced: 1. start with nano installed and configured as ${EDITOR} 2. edit rc.conf so that EDITOR=/usr/bin/your_favorite_editor (vim, of course :-) 3. emerge fcron vim That will probably fail (not tested) during the configure of fcron: ... checking for sh... /bin/bash checking editor... configure: error: File /usr/bin/your_favorite_editor is not an executable file ... As far as I am consirend the bug is ONLY about install because if you choose vim as editor and fcron as crond (during the GUI install), fcron is merged before vim, but after the rc.conf has been fixed, AFAIR. Guys, this bug is for 2006.0 and I don't think anybody is using that now... I'll mark it RESOLVED:WONTFIX on Monday if noone disagrees. Feel free to reopen if that springs in some other context. To Comment #5: Kyle, can you reproduce that again? What did you do? What was ${EDITOR} at that time and did you have nano and vim installed? We have enough other bugs to fix ;-)
Well. I've posted possible solution in bug #149376 comment #26. Possible implementation for cronbase and fcron you can find at: https://overlays.gentoo.org/dev/pva
I'm sick of this. =sys-process/fcron-3.0.1-r2 now depends on nano. feel free to reopen this if you're unhappy with it.
Please reopen! Don't make users install an editor which they aren't going to use anyway. Not everybody uses or likes nano...
I'm fix it in new ebuild. Check this in bug 149376.
Please re-open. I've read all the arguing in this and other threads over the issue, and I'll just say this: forcing users to install a package (ie, nano) that is neither a mandatory dependency nor something they want on their system is even more antithetical to the Gentoo philosophy than any of the $EDITOR hacks mentioned here. The forced dependency on nano is the easies, but still worst, possible fix for this issue.
Why don't you go and tell upstream to fix this, instead of whining here and asking me to patch something that I'm certainly not willing to patch at all? :)
