Hello On Tue, Dec 21, 2004 at 07:01:31PM +0100, Bjoern Steinbrink wrote: > On 2004.12.21 18:09:29 +0100, Ola Lundqvist wrote: > > Hello > > > > I know that this thread is old but I have to answer as I'm the > > maintainer. > > > > On Tue, Nov 09, 2004 at 03:53:42PM +0100, Björn Steinbrink wrote: > > > On Tue, 9 Nov 2004 14:35:18 +0000 (UTC) > > > Jesper Krogh <[EMAIL PROTECTED]> wrote: > > > > > > > I gmane.linux.vserver, skrev Herbert Poetzl: > > > > > > > > > > yes, it is also common practice to avoid debian > > > > > to get a working linux-vserver setup ... > > > > > > > > For any particular reason? > > > > > > Because debian packages are made to work with debian packages. That > > > means that if you use the debian util-vserver package it is best to use > > > their kernel patch and their helper stuff, it won't work too well with > > > non debianized stuff. Problem is: debian stuff is often outdated, f.e. > > > from what i remember debian has an (old) vserver patch for 2.6 (devel), > > > but the tools are kept at 0.30 (stable), thus you can't use the new > > > features (except if the debian maintainers wrote/backported tools...). > > > > I would like to say like this: Debian tend to ship well tested > > and stable versions. The kernel patch for 2.6 kernel was an experiment > > and I actually think it was a bad idéa to add it there. I have got > > many misunderstandings about this version. > > > > No problem with that statement, but my point was a little different. For > example, IIRC debootstrap in woody seems to rely on a bug in the sed version > that comes with woody, if you use a backported sed version with that bug > fixed, debootstrap breaks. The packages are made to work with each > other, not with what happens to be upstream. And from what i heard Yes and that is the reason why the debian tools depend on a deboostrap > 0.2.0 so that this issue is fixed. So if you backport you have to backport both vserver-debiantools and deboostrap.
> debian's util-vserver also differs from upstream behaviour (f.e. > /var/lib/vservers instead of /vservers as the vserver directory [bad > example...]), so that may increase the trouble the upstream maintainers > may have to go through. Yes and the reason is to follow debian policy. Personally I use /vservers but I have to follow policy. I think it is good to be able to set it. Many people will probably want to use /srv/vservers as /srv is supposed to be used for this kind of things. > > > Also, since some packages have very little in common with the upstream, > > > it's a real pain to fix issues if you don't happen to be the debian > > > maintainer. > > > > Patches are always welcome! > > > > > You should have a look at the list's > > > archives and search for message from/to debian maintainers, maybe that > > > helps understanding why, for linux-vserver, the debianized stuff is not > > > the first choice. > > > > I would like to tell that util-vserver on 2.4 is very well tested. The > > reason why the 2.6 version is not included in Debian is that is is not > > stable (still development as far as I know). > > > > If debian's util-vserver package + the vserver package is stable then > that is great, but a good number of folks try to use the util-vserver > package with 2.6 kernels and that is really a bad idea... Yes and I do not have a good solution to this unless there is a stable (not developement) release that support 2.6. > > > That said, i want to say that i've used debian a long time and i like > > > it, but sometimes their (or a maintainer's, dunno) packaging policies > > > don't fit a project very well. Linux-VServer is such a project as it > > > seems. > > > > Well I do not really see your problem here. If you want to use > > development branch you have to use it from upstream. Stable versions > > is what is intended for release, or do I misunderstand something here? > > My comment was based on the fact that the 2.6 patch was included into the > debian package, but the appropriate tools were not. Your argument was > that the tools weren't stable yet. The result was a kernel-patch > package that depended on tools not really suitable for it. Policy-wise i > meant that the kernel-patch package wasn't split up into a 2.4 and a 2.6 > package, each one depending on its own suitable tools. Maybe I should > just have said that it was a bad idea to include the 2.6 kernel-patch ;) Yes it was a bad idea. I'll remove it. > Suggestions: > Split up the kernel patches into two package. Include the alpha tools as > a second tools package and set correct dependencies for all packages > (keep in mind that 2.4 kernel should work with alpha tools as well...). > Later you could probably drop the old tools package and exclusivly use > the no-longer-alpha tools. > or > Put a big note onto the package telling folks not to mix the debian > util-vserver package with upstream stuff, especially 2.6 kernel patches. > And if possible remove the 2.6 kernel-patch from the debian kernel-patch > package until you get the time/possibilty to fully support. Good idea. I'll start with removing the 2.6 kernel patch version. Regards, // Ola > Bjoern > _______________________________________________ > Vserver mailing list > [EMAIL PROTECTED] > http://list.linux-vserver.org/mailman/listinfo/vserver > -- --------------------- Ola Lundqvist --------------------------- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --------------------------------------------------------------- _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver