From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Mon 27 Dec 2004 - 22:18:31 GMT
sfrost_at_snowman.net (Stephen Frost) writes:
>> > | * pkglibdir is /usr/lib/util-vserver instead of /var/lib/util-vserver
>> ??? this is standard in autoconf packages.
> I was wondering a bit about this myself.. The difference between
> /usr/lib and /var/lib is pretty clear- is there stuff in util-vserver
> that modifies things in the /usr/lib/util-vserver install?
No, everything under /usr/lib/util-vserver is touched by 'make *install'
only. Neither a tool, nor the administrator should change something
>> > | * /etc/vserver/util-vserver-vars
>> Please do not install 'util-vserver-vars' into /etc. There is nothing
>> which can be changed at runtime across the entire toolset (binaries have
>> the values statically compiled in). The file is badly named and should
>> be called 'util-vserver-consts' instead of.
> I agree about the naming,
Chances are high that its naming and function was inspired by INNs
'innshellvars' file. ;)
> 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.
> (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
* you can configure tools with special paths at ./configure time
* execve(2) is more efficiently than execvp(3)
>> > | * Both /usr/include/ and /usr/lib/pkgconfig/ are installed by
>> > | default. What is include/vserver.h installed for?!
>> Support for 3rd party language bindings were the main idea behind an
>> libvserver library. Dunno, if there is much interest in such ones but I
>> do not see reasons not to ship the -devel files.
> Is the API/ABI adequately supported to really allow for people to be able
> to develop against it and depend on it? I'm guessing 'no' considering on
> 0.30.195 it looks like I've got a 'libvserver.so.0.0.0'. If the API/ABI
> isn't handled correctly through soname and soversion changes and whatnot
> then they should *not* be included in Debian.
Ok, as long as the tools are labeled 'alpha' I do not intend to introduce
>> > | * The distclean target does also remove util-vserver.spec which is
>> > | shipped in the release tarball.
>> Where is the problem? The corresponding clean-rule is autogenerated
>> by autoconf and the file can be recreated by './configure' resp.
> Sounds like maybe it shouldn't be shipped in the release tarball
No, it must be shipped. Else 'rpmbuild -ta util-vserver...tar.bz2' would
not work anymore.
Vserver mailing list