From: Kilian Krause (kk_at_verfaction.de)
Date: Mon 27 Dec 2004 - 15:26:45 GMT
Hi Enrico,
> > | * /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 don't. There's no single rule which would put it there in my
packaging. Thus this is coming from the install or install-distribution
targets.
If i did copy the specfile wrong, i'm sorry for that. That's why i'm
asking what target is to be called.
Yet the option to allow a relocation of the default vserver rootdir
would be highly appreciated. (and IMHO broken if not availble at all)
>
> > | * util-vserver contains a large number of utilities - binaries and
> > | shell scripts. These utilities serve different purposes and belong
> > | to different conceptual layers.
>
> 'contrib/manifest.dat' contains the proposed grouping/subpackaging. See
> the %install stage of the shipped .spec file for ways how to use it.
Ok, will check that. Thanks.
>
> > | * 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.
Has so far only _one_ app been coded outside the util-vserver domain? If
not, i'd vote for leaving this out until someone complains.
>
> > | * It would be very convenient if upstream could ship the graphviz
> > | output with the releases, such that building for Debian doesn't
> > | require graphviz.
>
> How is this handled in other Debian packages with 'doxygen' support? I
> would like to ship only the files which are really needed to build the
> package.
I need: doxygen, tetex-bin, tetex-extras, gs, graphviz
alltogether to build the "doc" target. And shipping only the "needed to
build" sounds like a good idea as that IMHO involves a static doc
already.
>
> > | * What is recommended for packaging, running both install and
> > | install-distribution (along with make all doc) or just make install?
>
> The 'install-distribution' target installs files outside of $(prefix). These
> are the /vservers directory and the /sbin/vshelper symlink.
>
>
> > | * 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'.
The point is you don't delete files you ship in the release tarball.
Thus if the spec is included in the official tarball the clean shouldn't
remove it.
>
> > | * There is a number of compile warnings. Some of them sound
> > | like they should be fixed. Are they ok as can be seen at:
> > | http://backend.verfaction.de/~kk/util-vserver/buildlog_stderr.log
>
> The only true ones are the missing strchr()/strlen() declarations and
> the unknown '\params' doxygen directive. First issue should be solved in
> CVS some time ago, latter will be fixed soon.
>
> The other warnings are caused by incomplete and currently unused
> code (vserver-start/*), support for the kernel 2.4 API and missing
> documentation.
Ok, sounds fine to me. =)
> > | # remove newvserver.defaults (because that is linuxconf and that is not
> > | supported in debian).
> > | rm -f $(CURDIR)/debian/util-vserver/etc/vservers/newvserver.defaults
>
> this should not be installed by 'make install*'.
ok, will check that.
>
> > | # New since SID for they are not standard for a Debian binary package
> > | rm -rf $(CURDIR)/debian/util-vserver/usr/include/
> > | rm -rf $(CURDIR)/debian/util-vserver/usr/lib/pkgconfig/
>
> I do not understand the reason behind this...
If i'd leave in the include/vserver.h i'd need to make a libvserver-dev
package. Thus not shipping no header at all is the clean solution here.
And the pkgconfig isn't used on Debian, thus no need to ship it either.
-- Best regards, Kilian
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver