On Mon, Dec 27, 2004 at 08:16:54PM -0500, Stephen Frost wrote: > * Enrico Scholz ([EMAIL PROTECTED]) wrote: > > [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? I'm thinking > it might go in /usr/share/util-vserver then, since it's not > system-dependent and isn't configurable. The other option would be > /usr/lib/util-vserver, either would be fine with me. > > > > (or installed by make install- is it?), but I'm a little concerned > > > about some of the constants that are in there- what's the problem with > > > searching the path for things like awk, grep, etc? > > > > Some might be unneeded, but: > > > > * /sbin might be missing in $PATH (it happens that 'vserver ... start' > > cleans the environment, or when vshelper is called by the kernel > > directly) > > vserver should only be run by root, no? If root doesn't have sbin in > his path then there's something not right. dpkg handles this by > checking for the things it needs being in the path and bailing if > they're not. > > Not entirely sure what to tell you about vshelper and being called by > the kernel... That's just an odd situation. :) Is there any > environment at that point, coming from *somewhere*?
yes, there is an environment and it is coming from the kernel ... currently that is: char *envp[] = {"HOME=/", "TERM=linux", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", plus three further vars: snprintf(cmd_buf, sizeof(cmd_buf)-1, "VS_CMD=%08x", cmd); snprintf(uid_buf, sizeof(uid_buf)-1, "VS_UID=%d", current->uid); snprintf(pid_buf, sizeof(pid_buf)-1, "VS_PID=%d", current->pid); > > * you can configure tools with special paths at ./configure time > > Yeah, so, that doesn't exactly cut it when we're talking about something > that goes into a binary package. :P > > > * 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 I don't recall > anything where performance changes at that level would make a bit of > difference in the vserver stuff. > > > Ok, as long as the tools are labeled 'alpha' I do not intend to introduce > > so-naming. > > Fair enough, then they won't be included in Debian as seperate packages > for people to develop against. well, maybe we should try to get out of alpha in near future as I think we will need non-alpha tools for a stable 2.6 release ... > > > 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? That'd work > too... > > Stephen best, Herbert > _______________________________________________ > Vserver mailing list > Vserver@list.linux-vserver.org > http://list.linux-vserver.org/mailman/listinfo/vserver _______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver