From: Stephen Frost (sfrost_at_snowman.net)
Date: Tue 28 Dec 2004 - 01:16:54 GMT
* Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de) wrote:
> 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? 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*?
> * 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.
> > 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
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver