Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

2005-04-21 Thread Paul de Vrieze
On Wednesday 20 April 2005 17:25, Christian Parpart wrote: > > I might be wrong, but... I do not think that this will be easily > possible, because all modules would have to deel with this, too. > > > Besides all this, suppose the case that we've an apache httpd 2.1-line > would in the trees, someo

Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

2005-04-20 Thread Donnie Berkholz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lance Albertson wrote: > Why do you have to > push all these improvements on the current stable line of apache (2.0.x) ? Why > can't these changes just be used in the upcoming alpha/beta releases and > totally > be implemented by the time they move to

Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

2005-04-20 Thread Francesco Riosa
Elfyn McBratney wrote: [snip] > - have the newer apache ebuilds migrate from old-style to new-style config > (very hard to do, but possible) > > By the way, why not choose this occasion to switch using utf8 ? Not an expert in character collation and similar, I'm experimenting this: /etc/apach

Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

2005-04-20 Thread Lance Albertson
Christian Parpart wrote: > On Wednesday 20 April 2005 2:14 pm, Lance Albertson wrote: > >>Christian Parpart wrote: >> >>>And yeah, I disagree to a move-back, too!! I'm most likely not to support >>>this in any kind, instead, I'd be willing in pushing p.mask'ed apache >>>httpd 2.1 into the tree, so

Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

2005-04-20 Thread Christian Parpart
On Wednesday 20 April 2005 10:59 am, Paul de Vrieze wrote: > On Wednesday 20 April 2005 09:36, Christian Parpart wrote: > > And yeah, I disagree to a move-back, too!! I'm most likely not to > > support this in any kind, instead, I'd be willing in pushing p.mask'ed > > apache httpd 2.1 into the tree

Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

2005-04-20 Thread Christian Parpart
On Wednesday 20 April 2005 2:14 pm, Lance Albertson wrote: > Christian Parpart wrote: > > And yeah, I disagree to a move-back, too!! I'm most likely not to support > > this in any kind, instead, I'd be willing in pushing p.mask'ed apache > > httpd 2.1 into the tree, so, that I don't have to live wi

Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

2005-04-20 Thread Lance Albertson
Christian Parpart wrote: > And yeah, I disagree to a move-back, too!! I'm most likely not to support > this > in any kind, instead, I'd be willing in pushing p.mask'ed apache httpd 2.1 > into the tree, so, that I don't have to live with the old shitty behavior > again. > > Seriousely, why did

Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

2005-04-20 Thread Paul de Vrieze
On Wednesday 20 April 2005 09:36, Christian Parpart wrote: > And yeah, I disagree to a move-back, too!! I'm most likely not to > support this in any kind, instead, I'd be willing in pushing p.mask'ed > apache httpd 2.1 into the tree, so, that I don't have to live with the > old shitty behavior agai

Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

2005-04-20 Thread Christian Parpart
On Tuesday 19 April 2005 10:51 pm, Paul de Vrieze wrote: > On Tuesday 19 April 2005 21:45, Elfyn McBratney wrote: > > APR and APU are stand-alone and independent of apache, so there is no > > need to p.mask those libs. > > They do not coexist with the old apache2 properly as apache2 includes it's >

Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

2005-04-19 Thread Paul de Vrieze
On Tuesday 19 April 2005 21:45, Elfyn McBratney wrote: > > APR and APU are stand-alone and independent of apache, so there is no need > to p.mask those libs. They do not coexist with the old apache2 properly as apache2 includes it's own version. As did subversion. Paul -- Paul de Vrieze Gentoo

Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

2005-04-19 Thread Elfyn McBratney
On Tuesday 19 Apr 2005 20:31, Paul de Vrieze wrote: > On Saturday 16 April 2005 14:38, Paul Varner wrote: > > On Sat, 2005-04-16 at 06:56 +0100, Elfyn McBratney wrote: > > > The way I see it, we have three options: > > > - package.mask (downgrades for those early adopters) > > > - keep the same l

Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

2005-04-19 Thread Paul de Vrieze
On Saturday 16 April 2005 14:38, Paul Varner wrote: > On Sat, 2005-04-16 at 06:56 +0100, Elfyn McBratney wrote: > > The way I see it, we have three options: > > - package.mask (downgrades for those early adopters) > > - keep the same layout (/etc/apache2/conf, etc.) and wait until 2.2 is > > out

Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

2005-04-16 Thread Paul Varner
On Sat, 2005-04-16 at 06:56 +0100, Elfyn McBratney wrote: > The way I see it, we have three options: > - package.mask (downgrades for those early adopters) > - keep the same layout (/etc/apache2/conf, etc.) and wait until 2.2 is out to >change it > - have the newer apache ebuilds migrate fro

Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

2005-04-15 Thread Lance Albertson
On Sat, 2005-04-16 at 06:56 +0100, Elfyn McBratney wrote: > As I'm sure many of you will know, the updated apache and associated ebuilds > (so-called apache refresh) have caused a number of problems since coming out > of package.mask and going into testing. As a result, we have a number of > p

[gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

2005-04-15 Thread Elfyn McBratney
Hi Folks, As I'm sure many of you will know, the updated apache and associated ebuilds (so-called apache refresh) have caused a number of problems since coming out of package.mask and going into testing. As a result, we have a number of packages that simply do not function with the updated apa