Adrian Reyer wrote: > Hello Daniel, > > On Sun, May 22, 2011 at 01:39:29AM +0200, Daniel Hokka Zakrisson wrote: >> Just add --with-vrootdir=/var/lib/vservers to debian/rules > > Yes, that has been my first approach, but coming from a 'normal' Debian > version this gives all sorts of warnings and error messages about files, > links and directories. Such as? > The startup-scripts are quite a few less in the Debian-version and > include FHS-compliant headers enabling other init systems to > automatically deal with them as well. Strangely when I check the > original it seems to have just the right headers while I am quite > confident I only saw 'chkconfig XX YY' stuff. The LSB headers have been there for years. The one giant initscript thing that Debian does really isn't a good idea... > Additionally the Debian package uses debconf to treat VServers somewhat > like database data on package removal, it asks if they should stay > nonetheless. I never want packages touching my data, or even looking at my data. Then again, I am vehemently opposed to packages asking questions... >> > correctly. Is there any reason the Debian-enhanced debian-directory is >> > not within the util-vserver directory but instead a version that looks >> > like a dummy to me? >> How is it a dummy? It's a completely functional package, packaged the >> way it is meant to be, instead of the checkinstall-like crap that is >> the Debian package. > > Don't get me wrong here. It might work perfectly well one for someone > who never used the Debian-provided package. For those who did, things get > nasty if they 'just upgrade' as it is more a 'crossgrade'. E.g. you come > from util-vserver startup script to util-vserver + vprocunhide, in my > first test vprocunhide got not automatically activated, at least not > before util-vserver (which had already been activated from the old > package). Additionally with my tests, /etc/vservers/.defaults/run.rev > got lost. Yes, don't just upgrade, unless you spend time on figuring out how to do so properly. The packages are meant to replace a from-source install, since nobody really should be using the Debian-packages. The util-vserver and vprocunhide initscripts are orthogonal. vservers-default on the other hand, depends on them both. They're all set to get activated in postinst, so if you figure out why it didn't work for you... >> I don't understand how the GPLv2 fits in here? > > All copyright notices I found within the code stated GPLv2, I have not > seen anything about mentioning names of authors in the GPLv2. But many > of the changes have much to do with names being replaced, especially due > to the changelog being replaced. You always need to retain authors. >> Why exactly doesn't the util-vserver package work for you? > > Described that above. And as it initially failed I didn't do many tests > as in the thread "[vserver] is default squeeze kernel and util-vserver > ok?" Ben stated "Getting from utils-vserver-basic-debian to util-vserver > is not pleasant". Perhaps I had just let myself be scared away to easily. That is a completely different package. -- Daniel Hokka Zakrisson