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
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
