Re, -(snip)- > rebootmanager is obsoleted since a long time > (it was replaced by vshelper)
ok, fine. yet the make install or make install-distribution does still yield it. That's nothing i would copy within the debian/rules. > | - How should the packaging devide up the groups most conveniently? > > util-vserver-0.30.196 > util-vserver-lib-0.30.196 > util-vserver-sysv-0.30.196 > util-vserver-core-0.30.196 > util-vserver-build-0.30.196 > util-vserver-legacy-0.30.196 ok, we'll try to bring that to the debs. Is there a list which files should go into which of these packages? > | * 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) is already the case for debian. the linux-kernel-log-daemon is the virtual package for a klogd (as opposed to sysklogd | system-log-daemon) > | * 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 ... It's not that we'd have requested it. The alpha tools still ship it. =) The list of files contained in the package can be found in the lower part of: http://backend.verfaction.de/~kk/util-vserver/util-vserver_0.30.196.build where it reads "chroot-unstable/build/wanna-build/util-vserver_0.30.196-1_i386.deb:"... > | * 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 ... which is why i had quoted it like "newserver" for i know it's no longer current. The idea was though to just create a vserver config file in /etc/vserver/ and all else it takes to make it vserver-bootable from a given chroot without moving it around. Like running the skeleton installer upon a given chroot dir which is then probed for the needed binaries/scripts. (so far the idea *g*) -- 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