Forgive me if I am overlooking something, but as far as I see 1. webapp-config depends on gentoolkit, *only* because it needs portageq 2. webapp-config needs portageq to lookup $CONF_LIBDIR 3. webapp-config needs to lookup $CONF_LIBDIR in order to find $MY_LIBROOT 4. webapp-config needs to find $MY_LIBROOT because that's where it has installed its files I think that it is more proper to hardcode that location at compile time, instead of looking it up at execution. A simple sed would do trick.: --- /usr/portage/net-www/webapp-config/webapp-config-1.10-r11.ebuild 2004-09-22 09:13:10.000000000 +0900 +++ ./webapp-config-1.10-r11.ebuild 2005-03-19 19:22:17.000000000 +0900 @@ -30,7 +30,11 @@ } src_install() { - dosbin sbin/webapp-config + sed \ + -e '/^MY_PORTAGEQ=/,+1 d' \ + -e "/^CONF_LIBDIR/ s:=.*:=$(get_libdir):" \ + < sbin/webapp-config > sbin/webapp-config.new + newsbin sbin/webapp-config.new webapp-config dodir /usr/$(get_libdir)/webapp-config cp -R lib/* ${D}/usr/$(get_libdir)/webapp-config/ dodir /etc/vhosts
Regarding 1. -- portageq is actually provided by portage. So why does webapp-config depend on gentoolkit? Anyway, my real problem is not that dependency, but the fact the webapp-config slows down by running portageq. I'm changing the summary to reflect my *real* problem. Old subject: webapp-config should not RDEPEND on gentoolkit
Hi, get_libdir() is only available inside ebuilds, so unfortunately I can't use that. Running portageq is the only official way to get the correct libdir on multilib systems atm. webapp-config depended on gentoolkit because it used qpkg. It now uses equery, which is still part of gentoolkit. Best regards, Stu
Oh, I forgot - webapp-config also uses portageq to work out which directories are config-protected, and which are not. Best regards, Stu
Please read my patch again: + sed \ + -e '/^MY_PORTAGEQ=/,+1 d' \ + -e "/^CONF_LIBDIR/ s:=.*:=$(get_libdir):" \ The double quotes were intentional, as to not add the literal '$(get_libdir)', but rather its return value. Thus get_libdir is only used in the ebuild. See a diff between the webapp-configs installed by the current -r14 and a -r11 patched as above: diff -u webapp-config-1.10-r1{4,1}/image/usr/sbin/webapp-config | head -n 13 --- webapp-config-1.10-r14/image/usr/sbin/webapp-config 2005-05-31 01:04:49.000000000 +0900 +++ webapp-config-1.10-r11/image/usr/sbin/webapp-config 2005-05-31 01:04:38.000000000 +0900 @@ -19,9 +19,7 @@ # # see http://bugs.gentoo.org/62018 -MY_PORTAGEQ="`which portageq`" -CONF_LIBDIR="`${MY_PORTAGEQ} envvar CONF_LIBDIR`" -CONF_LIBDIR=${CONF_LIBDIR:=lib} +CONF_LIBDIR=lib64 # ======================================================================== # Some configuration variables > Oh, I forgot - webapp-config also uses portageq to work out which directories > are config-protected, and which are not. OK, I have nothing to say abou that invocation. However, I still think that you could easily remove the first portageq (as requested by this bug). The speedup is considerable.
I prefer to determine configuration at runtime as much as possible. The current approach works on all supported arches, and no-one has to worry in the unlikely event of the webapp-config script being copied manually from one type of box to another. I'm surprised that the speedup is noticable on kit which needs get_libdir support. The call to portageq is a tiny fraction of the elapsed time webapp- config takes. Maybe it'll be more of an issue once webapp-config is written in a faster language such as Python. Best regards, Stu
(In reply to comment #5) > I prefer to determine configuration at runtime as much as possible. The > current approach works on all supported arches, and no-one has to worry in the > unlikely event of the webapp-config script being copied manually from one type > of box to another. I'd say if someone is copying scripts manually from one location to another, and also copying stuff from /usr/lib64 to /usr/lib or the other way around, they should know better that they may need to touch something somewhere. Even if they don't, they'd soon find out. You could also set MY_LIBROOT in /etc/...somewhere and forget about CONF_LIBDIR. Furthermore, portageq is not helping approach the ultimate goal of making webapp-config available for other distros. > I'm surprised that the speedup is noticable on kit which needs get_libdir > support. The call to portageq is a tiny fraction of the elapsed time webapp- > config takes. Maybe it'll be more of an issue once webapp-config is written > in a faster language such as Python. I never said that the machine where I use webapp-config needs get_libdir support (it doesn't). Regarding the noticeable speedup, here go three runs of webapp-config with a call to portageq: root@tiger ~ # time webapp-config --help >/dev/null real 0m7.359s user 0m2.032s sys 0m0.514s root@tiger ~ # time webapp-config --help >/dev/null real 0m2.271s user 0m1.976s sys 0m0.268s root@tiger ~ # time webapp-config --help >/dev/null real 0m2.100s user 0m1.806s sys 0m0.291s That's at least two seconds to read the help. Now removing the call to portageq and: root@tiger ~ # time webapp-config --help >/dev/null real 0m0.143s user 0m0.080s sys 0m0.062s root@tiger ~ # time webapp-config --help >/dev/null real 0m0.137s user 0m0.070s sys 0m0.065s --help is a good example for an option that needs a speedy response. Others would include the --list-* and --show-* options. Two seconds for the output of those is too much (7 seconds if the portage tree is not cached yet).
