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

From: Stephen Frost (sfrost_at_snowman.net)
Date: Thu 17 Feb 2005 - 19:02:27 GMT

* Lars E. D. Jensen (lars_at_dangvard.dk) wrote:
> Torsdag den 17. februar 2005 18:30 skrev Micah Anderson:
> > Stephen Frost schrieb am Thursday, den 17. February 2005:
> > > > well, then maybe the debian very-unstable/development-testing branch
> > > > would fit better (no idea what the debian policies are ;)
> > >
> > > The issue with this is that Debian is looking to release and things in
> > > unstable migrate to testing and then eventually will be released with
> > > stable. unstable isn't really a whole seperate tree in that sense, at
> > > least, not right now. After stable is released it'll go back to being
> > > the latest-greatest that compiles and works after a cursory test.
> >
> > It is possible in Debian to have things put into unstable, and keep
> > them from migrating into Sarge. There are many packages that are being
> > held back from moving into testing so that Sarge can release. It is
> > perfectly reasonable to put the vserver "development" tools into
> > unstable and keep them out of Sarge... if you dont want to go that
> > route, there is also the experimental repository. However, in my
> > experience the vserver "development" tools are really stable.

(I don't appear to have gotten this message, kind of odd, but whatever)
My feeling is also that the vserver "development" tools are quite stable
and I really wish they'd release a 'stable' version of them so the current
Debian maintainer of vservers would put it in unstable (and even let it
migrate to testing/sarge). The mechanisms for keeping things in
unstable that shouldn't go into sarge are less than perfect, and make it
more difficult to update what's going into sarge. It's unfortunate, but
there it is. It's gotten a little better but there's still alot of room
for improvement.

> IMHO putting vserver patch into unstable isn't good seen from a production
> environment pov.
> The ideal solution to me would be to use the official debianized 2.6.10 from
> unstable and backport this to testing release (including the Debian patches
> if possible) with the newest 1.9.4 vserver patch.

2.6.10 should be making its way into testing/sarge and is planned to
become the 2.6 kernel for d-i as well, I believe.

> Make it possible to apply the newest vserver patch to current 2.6 kernel in
> Debian testing.

This is certainly something I'm all for, and were the Debian maintainer
of vserver going to upload a kernel-patch for 1.9.4 I'd be happy to help
him create that package such that it patches cleanly against Debian
kernel sources (again, not hard to do, really).

> This would fit as a good base for a production environment since you get
> vserver bugs out of the way and get newest features. The latter is best I
> think, but demands more work since it's probably more difficult to apply a
> 1.9.4 vserver patch on a 2.6.8 kernel (testings 2.6 kernel) - if possible at
> all...

Well, since we're moving to 2.6.10 and it's not too bad to get 1.9.4
patched against 2.6.10 I think that's probably the way to go...

> Of course this would also have to be maintained by a cool kernel-source
> debianizer, who sadly isn't me :(

Debian kernel-patches aren't hard to create, and the Debian maintainer
of vservers has done it before.

> But I don't know if you think this is a good idea.

I think it's a good idea, but I'm not the current maintainer, just
another DD.


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 Thu 17 Feb 2005 - 19:02:24 GMT by hypermail 2.1.3