From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Mon 27 Dec 2004 - 01:54:13 GMT
On Mon, Dec 27, 2004 at 02:36:24AM +0100, Kilian Krause wrote:
> 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
> http://backend.verfaction.de/~kk/util-vserver/TODO alongside with
> preliminary alpha debs which can be used with
> "deb http://backend.verfaction.de/~kk/util-vserver/ ./" in
> sources.list.. Comments and feedback are welcome.
okay, here the list, so that I can comment ...
| * A lot of programs don't have documentation. Add man pages in DocBook?
| - chxid
| - exec-cd
| - lsxid
| - setattr
| - showattr
| - vapt-get
| - vattribute
| - vcontext
| - vdu
| - vfiles
| - vkill
| - vlimit
| - vnamespace
| - vrpm
| - vrsetup
| - vsched
| - vserver-info
| - vshelper
| - vuname
| * pkglibdir is /usr/lib/util-vserver instead of /var/lib/util-vserver
| * /etc/vserver/util-vserver-vars VROOTDIR doesn't affect
| * util-vserver contains a large number of utilities - binaries and
| shell scripts. These utilities serve different purposes and belong
| to different conceptual layers.
| It appears there is or may be:
| a) Stuff for basic administration.
| Command line interfaces to the vserver syscalls and the like.
yes, they are part of the lib and core packages
(on rpm based systems)
| b) Higher-level stuff.
| I) Used only on host systems.
| Like rebootmgr, vserver start and stop scripts, etc.
rebootmanager is obsoleted since a long time
(it was replaced by vshelper)
| II) Used only on guest systems.
| Is there something like this?
not that I know of ... at least not in recent systems
| III) Used on both host and guest systems.
| Is there something like this? lsxid? chxid?
not that I know of either ...
| - Which are the binaries for each group and have we listed all
| - How should the packaging devide up the groups most conveniently?
| - Very likely a shared lib package should be included only once if
| there is more than one binary package.
| * guest systems cannot run klogd (because there is only one kernel and
| the klogd thus is best addressed in the host system).
| So a distribution has to ship an empty dummy package to satisfy the
| packages which depend on klogd (Debian: linux-kernel-log-daemon).
hmm, this is a kernel issue, and maybe we can solve
that at this level (by providing a fake or empty
connection point for klogd) but IMHO it would be best
to break up the syslog package into syslogd and klogd
(which would render this point obsolete)
| * Both /usr/include/ and /usr/lib/pkgconfig/ are installed by
| default. What is include/vserver.h installed for?!
| Do we need a -dev package?
| * Is the api documentation to be split into a separate -doc package?
| * Repeatedly calling "rebootmgr start" starts multiple processes.
| This is bad.
as I said, rebootmgr is obsoleted, don't use it
don't package it, just let it die in peace ...
| * Is there up-to-date documentation for /etc/vservers/NAME/* ?
included as xml file in the source of util-vserver
| * It would be very convenient if upstream could ship the graphviz
| output with the releases, such that building for Debian doesn't
| require graphviz. (graphviz is marked non-free in Debian and thus
| would force util-vserver from main into contrib). Pre-building the
| graphviz output in the (maintainer-mode?) dist-target should be easy
| enough not not allow this to happen.
| Is it necessary for the entire "doc" target to be rebuilt at
| packaging time? If this could be moved to the "dist" target as well,
| that would speed up the packaging even more.
| * What is recommended for packaging, running both install and
| install-distribution (along with make all doc) or just make install?
| * The distclean target does also remove util-vserver.spec which is
| shipped in the release tarball.
| Perhaps "make distcheck" and the resulting cleanups would help.
| * There is a number of compile warnings. Some of them sound
| like they should be fixed. Are they ok as can be seen at:
probably heavily depends on the used compiler ...
| * The current Debian package removes the following files before
| packaging, which upstream's "make install install-distribution"
| rm -f $(CURDIR)/debian/util-vserver/usr/lib/*.la
| # have to remove v_ init scripts
| rm -f $(CURDIR)/debian/util-vserver/etc/init.d/v_*
| # remove newvserver.defaults (because that is linuxconf and that is not
| supported in debian).
| rm -f $(CURDIR)/debian/util-vserver/etc/vservers/newvserver.defaults
| # 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/
| - Are they all needed/useful?
| - Can/should more be purged from a default install to make a
| "only-for-distribution" package?
| - Which tasks shall be executed upon installation? Which upon uninstall?
| - Which of /etc/init.d/v* need to be installed into the runlevels by default?
| Which should be left to the user to install?
| * Is there a script to convert existing chroots into vservers yet? If
| not, what's the closest we can get to write one from the "newvserver
| lower half"?
newvserver is not part of the utils IIRC, but
basically you can take a chroot as it is, add
the appropriate config, move it in place (or not)
and start any application within a context ...
> We'd appreciate if you could go through the TODO and help us with the
> open questions.
> The linda and lintian reports plus the build log are also in that
> Best regards,
> Vserver mailing list
Vserver mailing list