Hi! Currently portage dies when configure script is not executable or it's not present. The problem is that, as seen in a lot of ebuilds and some eclasses like games.eclass, this is being workarounded for running configure when script is present and simply skipping configure when it's not. You will also see (a "grep" run in PORTDIR will show you a lot of examples) that some ebuilds are manually adding +x permission to configure script. I suggest make portage not simply die when configure script is missing, with the attached patch applied to /usr/lib/portage/bin/ebuild.sh portage will: 1. If configure script doesn't have executable permission, it will run chmod +x for adding it to the script. This would allow drop a lot of repeated "chmods" from some ebuilds in the tree. Anyway, a message will be shown saying: " * econf: configure is not executable: fixing it..." allowing gentoo maintainers to send this problem upstream when possible 2. If configure script is not found, portage will simply skip configure stage. This is better because, commonly, apps without configure script simply don't need it, they are not missing it by error (anyway, if app needs configure script and it's not available, it usually fails to ebuild and gentoo maintainer will see it). This will allow a lot of ebuilds (and some eclass) to drop workarounds for this (see, for example, opera.ebuild or simply run "grep -r "true" /usr/portage/" and you will see a lot of ebuilds running "true" simply for skipping configure. This iss why I think that portage behavior should be modified I attach the patch now. I am using it since end of august and seems to work fine for me Thanks a lot for considering this :-) Reproducible: Always
Created attachment 167433 [details, diff] ebuild.sh.patch This is the patch, maybe it has some errors or things could be made simpler, feel free to improve it if you want, as I am not an expert of bash scripting :-(
This sort of change requires an EAPI bump since we don't want ebuild authors relying on new behavior in ebuilds that might be installed by an older version of portage.
OK, thanks for the information
The suggestion is also to skip configure if script is not found
(In reply to comment #4) > The suggestion is also to skip configure if script is not found That's just silly. Don't call econf if you don't want it to run.
(In reply to comment #5) > (In reply to comment #4) > > The suggestion is also to skip configure if script is not found > > That's just silly. Don't call econf if you don't want it to run. > I suggest not calling econf when no configure is found, but I suggest that this should be made directly by ebuild.sh (like original comment and patch do) instead of requiring (like currently) that each ebuild do it, this would allow to drop some repeated commands from some ebuilds (yes, I know that my last modification in summary can cause confusions because it's wrong, I modify it a bit for explaining it better. Sorry for the inconvenience)
Well, the patch is not doing exactly the same, it makes econf to return if doesn't found configure instead of simply dying. Maybe would be better that configure script were detected before calling econf, but I don't know what is the responsible of calling it :-/ Maybe in: src_compile() { if [ "${EAPI:-0}" == 0 ] ; then [ -x ./configure ] && econf elif [ -x "${ECONF_SOURCE:-.}/configure" ] ; then econf fi if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then emake || die "emake failed" fi }
(In reply to comment #7) > Maybe would be better that configure script were detected before calling > econf, but I don't know what is the responsible of calling it :-/ By default src_compile calls it in eapi 0 and 1 and src_configure in eapi 2. None of those default functions call econf unless they detected an executable configure script though. So what you're uncountering is most likely to be an eclass. Said eclass could easily make the econf conditional on the configure script being executable too. The question in that case is if making it unconditional was intentional because it's really required in all intended uses cases or if it's an eclass bug.
(In reply to comment #8) > By default src_compile calls it in eapi 0 and 1 and src_configure in eapi 2. > None of those default functions call econf unless they detected an executable > configure script though. So what you're uncountering is most likely to be an > eclass. Said eclass could easily make the econf conditional on the configure > script being executable too. The question in that case is if making it > unconditional was intentional because it's really required in all intended uses > cases or if it's an eclass bug. > You are true, sorry a lot, the ebuild I was trying was forcing "econf" execution (silly me!) Sorry for the inconvenience
This is probably not needed as only a small set of packages need this
