From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Mon 27 Dec 2004 - 13:32:04 GMT
[...I will abuse Herbert's posting because it contains the TODO list...]
herbert_at_13thfloor.at (Herbert Poetzl) writes:
>> Hi Enrico,
>> Hans Ulrich Niedermann and me have started reviewing the debian package
>> and put up some agenda we think should be clarified to ease packaging
>> (not only on Debian).
>> The TODO file with our questions can be found at
> | * A lot of programs don't have documentation. Add man pages in DocBook?
Maintainership of the man-pages will be a problem; especially in
the current stage where features might be added or removed very
fast. Incorrect documentation is worse than missing one.
> | * pkglibdir is /usr/lib/util-vserver instead of /var/lib/util-vserver
??? this is standard in autoconf packages.
> | * /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.
> | * 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.
> | * 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.
> | * 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
> | * 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.
> | * 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
> | * The current Debian package removes the following files before
> | packaging, which upstream's "make install install-distribution"
> | installs:
> | rm -f $(CURDIR)/debian/util-vserver/usr/lib/*.la
ok with me. Done in the .spec file also
> | # have to remove v_ init scripts
> | rm -f $(CURDIR)/debian/util-vserver/etc/init.d/v_*
The v_* scripts are stuff from the old toolset. I do not like them as
most handled services do not belong into the host-server and/or have
their own ways to bind to a certain interface. So, feel free to remove
> | # 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*'.
> | # 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...
Vserver mailing list