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 ZakrissonReceived on Sun May 22 13:03:46 2011