From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Tue 28 Dec 2004 - 02:49:48 GMT
sfrost_at_snowman.net (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_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver