[EMAIL PROTECTED] (Stephen Frost) writes: >> > and that it perhaps shouldn't even be packaged at all >> >> No, things like $PACKAGE_VERSION are changing with every version and >> must be told to the single scripts. Same holds for the configured paths. > > So, it's used by scripts *and* is compiled into programs?
Yes; e.g. ,--- pathconfig.h.pathsubst --- | #define MOUNT_PROG "@MOUNT@" ,--- src/secure-mount.c --- | if (mount_prog==0) mount_prog = MOUNT_PROG; | ... | execv(mount_prog, const_cast(char **)(argv)); Or | $ strings /usr/lib/libvserver.so | ... | /vservers/.pkg | /etc/vservers/.defaults/run.rev > I'm thinking it might go in /usr/share/util-vserver then, since it's > not system-dependent it is system-dependent; e.g. on i386 it has | PKGLIBDIR='/usr/lib/util-vserver' x86_64 would have | PKGLIBDIR='/usr/lib64/util-vserver' > and isn't configurable. The other option would be /usr/lib/util-vserver, > either would be fine with me. it is expected in /usr/lib/util-vserver by default. >> * execve(2) is more efficiently than execvp(3) > > Is there something in here that actually would notice from such a > change? Seriously, is there *really* some benefit here for an end user > or is this just a lame excuse thrown in at the end? :P using execvp(3) would mean: * trusting in $PATH that it contains the wanted path (this has to deal with packaging philosophies also which expect all 3rd party apps under /opt/<name>) --> /etc/profile.d/* et.al. must be executed before everything else * trusting in $PATH that it contains not too much (e.g. no '.'); we are operating in hostile environments (guest-servers) --> sanity checks for $PATH are required * iterating over all elements of $PATH and try execve() there With execve(2) you do not have these problems and both coding and runtime-executing is more efficiently. I do not see an advantage in guessing paths with execvp(3) over and over again, when they can be determined at buildtime. >> [ ... util-vserver.spec ...] >> > Sounds like maybe it shouldn't be shipped in the release tarball >> > then.. >> >> No, it must be shipped. Else 'rpmbuild -ta util-vserver...tar.bz2' would >> not work anymore. > > Hrmpf. Then can we just not delete it in make clean? I will think about this; but I still do not understand the problem there. Enrico _______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
