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

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.
>> './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.

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 Mon 27 Dec 2004 - 22:18:46 GMT by hypermail 2.1.3