[EMAIL PROTECTED] (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 there. >> > | * /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 directly) * 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 so-naming. >> > | * 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. >> './config.status'. > > 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. Enrico _______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver