About this list Date view Thread view Subject view Author view Attachment view

From: Kilian Krause (kk_at_verfaction.de)
Date: Mon 27 Dec 2004 - 02:07:04 GMT


> 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:

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,

Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Mon 27 Dec 2004 - 02:07:20 GMT by hypermail 2.1.3