From: Ola Lundqvist (opal_at_debian.org)
Date: Wed 22 Dec 2004 - 07:01:28 GMT
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 <jesper_at_krogh.cc> 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.
> 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.
> 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.
> Vserver mailing list
-- --------------------- Ola Lundqvist --------------------------- / opal_at_debian.org Annebergsslingan 37 \ | opal_at_lysator.liu.se 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 Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver