About this list Date view Thread view Subject view Author view Attachment view

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));


| $ 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

Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Tue 28 Dec 2004 - 02:50:04 GMT by hypermail 2.1.3