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

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

[Elfyn McBratney]

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

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 apache ebuilds, 
rendering testing (on the apache side of things) broken.

Currently, we have at least two (possibly three) weeks worth of work to do 
before we can mark things stable, so these breakages will likely exist until 
then.

A number of people have suggested putting these updated ebuilds back into 
package.mask, or lessening the impact of the upgrade from current stable 
apache to the new ~arch apache.  So, I would like to solicit advice from the 
developer community as to how we can rectify this.

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 from old-style to new-style config
   (very hard to do, but possible)

Personally, I'm for package.masking, heh.  Let the flames commence.

Best,
Elfyn

-- 
Elfyn McBratney                                     http://beu.merseine.nu/
beu/irc.freenode.net                            http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc

PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
  DBD3 B756 ED58 B1B4 47B9  B3BD 8D41 E597 69DF 17AD

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 2163 bytes --]

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 
> packages that simply do not function with the updated apache ebuilds, 
> rendering testing (on the apache side of things) broken.

Yes, this has gotten very annoying.

[snip]

> A number of people have suggested putting these updated ebuilds back into 
> package.mask, or lessening the impact of the upgrade from current stable 
> apache to the new ~arch apache.  So, I would like to solicit advice from the 
> developer community as to how we can rectify this.
> 
> 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 from old-style to new-style config
>    (very hard to do, but possible)

I say at the very least package.mask it. Testing is supposed to be able
to compile and work, not half work and test. There's a reason we have a
package.mask, please use it! To me, it makes more sense to push these
changes in the next major release of apache (2.1/2.2). 2.0.x should be
kept as is since a lot of people are using that now and any change
midway through the release would cause a lot of havoc.

So far, most of the changes don't seem to be backward compatible with
each other. Right now you can't make a module that will work for either
variation of the layout without hacking it badly. To me, thats bad
especially since the new layout isn't in package.mask.

I just fear if we continue to push these changes on the current 2.0.x
line will continue to piss off a lot of people.

Cheers,

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
Public GPG key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[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 from old-style to new-style config
>    (very hard to do, but possible)
> 

As a user whose apache install is completely hosed at the moment due to
these changes, my recommendation is all the above, with it being package
masked immediately.

Regards,
Paul
--
gentoo-dev@gentoo.org mailing list

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

[Duncan]

Elfyn McBratney posted <200504160656.43452@zippy.emcb.local>, excerpted
below,  on Sat, 16 Apr 2005 06:56:34 +0100:

> A number of people have suggested putting these updated ebuilds back into 
> package.mask, or lessening the impact of the upgrade from current stable 
> apache to the new ~arch apache.  So, I would like to solicit advice from the 
> developer community as to how we can rectify this.
> 
> The way I see it, we have three options:
>  - package.mask (downgrades for those early adopters)
[snip]

As a user that tends to get a bit upset when perfectly working (on my
system) packages are package masked, forcing a downgrade, without clear
reason, here's my perspective.

*  Put a clear explanation in the package-mask comment, particularly
indicating that it's safe to unmask and continue to use if you already
have it installed and working -- IOW, that it's not a security issue
causing the masking. Something like,

# Masked pending further development and testing.  Current working
# installations may package.unmask to prevent # forced downgrade.

Or, reference a bug number instead of that "pending" language.

Again, just clearly indicate the reason for any masking that will force a
downgrade, particularly whether it's security related or not, and the
consequences of /not/ downgrading, thus giving the user, that is, the
local Gentoo system administrator, enough information to make a good
decision on whether they can /safely/ package.unmask it and continue to
use it, or not.

I must say... In general, the Gentoo devs already get high marks for this.
=8^) Only once have I had to ask what the force-downgrade masking was
about, because all the comment effectively said was "remasking this",
something I obviously already knew if I was looking at the comment in the
package.mask file. =8^(  (Actually, I think that incident had to do with
keyword masking, but the point still stands.  Clear comment explaining
why, and I'm a happy camper <g>; unclear comment, and I'm not, because
I've been deprived of the information necessary to effectively carry out
/my/ responsibilities as a Gentoo sysadmin.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

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 to change it
> >  - have the newer apache ebuilds migrate from old-style to new-style
> > config (very hard to do, but possible)
>
> As a user whose apache install is completely hosed at the moment due to
> these changes, my recommendation is all the above, with it being package
> masked immediately.

I disagree. This will actually put you in an inconsistent state as the old 
apache overlaps with apr/apr-util. What I think would be the best solution is 
to undo the config changes, but keep the apr change in a new ebuild set that 
get's updated to (up or downgrading I don't care).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Elfyn McBratney]

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

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 layout (/etc/apache2/conf, etc.) and wait until 2.2 is
> > > out to change it
> > >  - have the newer apache ebuilds migrate from old-style to new-style
> > > config (very hard to do, but possible)
> >
> > As a user whose apache install is completely hosed at the moment due to
> > these changes, my recommendation is all the above, with it being package
> > masked immediately.
>
> I disagree. This will actually put you in an inconsistent state as the old
> apache overlaps with apr/apr-util. What I think would be the best solution
> is to undo the config changes, but keep the apr change in a new ebuild set
> that get's updated to (up or downgrading I don't care).

APR and APU are stand-alone and independent of apache, so there is no need to 
p.mask those libs.

Best,
Elfyn

-- 
Elfyn McBratney                                     http://beu.merseine.nu/
beu/irc.freenode.net                            http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc

PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
  DBD3 B756 ED58 B1B4 47B9  B3BD 8D41 E597 69DF 17AD

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

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 Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Christian Parpart]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

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
> own version. As did subversion.

AFAIK we can't have apr/apr-utils as standalone pkgs as long as we've 
subversion or apache2 still embedding it, that's been the reason for 
providing the ebuild patch for subversion (from the apache herd), too - I 
remember. Just embedding them again is really a great lost of at least 
maintainability, so at least do I feel.

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 we put all our power into those improvements when we're 
now about to revert mostly everything?

Regards,
Christian Parpart.

-- 
Netiquette: http://www.ietf.org/rfc/rfc1855.txt
 09:29:00 up 27 days, 22:35,  0 users,  load average: 0.01, 0.05, 0.00

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

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 again.
>
> Seriousely, why did we put all our power into those improvements when
> we're now about to revert mostly everything?

I believe that most issues are with the new configuration setup. What 
about checking for the old configuration format and in that case 
providing the old configuration setup. If there is no old format (or 
allready a working new format config file) use the new config system.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

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 we put all our power into those improvements when we're 
> now about to revert mostly everything?

Because they seriously hork people's installations in some cases and cause lots
of frustration. The improvements seem great, but they need to *work* out of the
box for most situations which this doesn't appear to be doing. Testing is
supposed to be for things that work and just need tweaking, not something that
works for most cases and breaks other people's systems. For one, make your
eclass backwards compatible so that mod plugins are easier to maintain. You're
not reverting if you're saving a lot of people some pain. 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 the next stable release. Asking people
to suddenly change midway through is a major pain. If they knew that these kinds
of changes were going to happen in >2.0.x, then it would be easier for them to
manage.

Cheers,

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operational Manager

---
Public GPG key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

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

[Christian Parpart]

[-- Attachment #1: Type: text/plain, Size: 3754 bytes --]

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 with the old
> > shitty behavior again.
> >
> > Seriousely, why did we put all our power into those improvements when
> > we're now about to revert mostly everything?
>
> Because they seriously hork people's installations in some cases and cause
> lots of frustration. The improvements seem great, but they need to *work*
> out of the box for most situations which this doesn't appear to be doing.
> Testing is supposed to be for things that work and just need tweaking, not
> something that works for most cases and breaks other people's systems. For
> one, make your eclass backwards compatible so that mod plugins are easier
> to maintain. You're not reverting if you're saving a lot of people some
> pain. 

> Why do you have to push all these improvements on the current stable 
> line of apache (2.0.x) ? 

I once read stuart's posting far along ago about needing help in apache herd. 
So I came in (and others). So we planned what needs to be solved as reported 
(tons of items were in bugzilla before), and what needs to be done to improve 
maintainship as well as client/hostadmin side configuration and workflow.
So we came up to the current feature set we currently have. And I'm really 
happy w/ our fixes and (far more) about the improvements we made.

Apache httpd 2.2-line isn't out there yet, so this wasn't an option at all 
(just once AFAIK and not related to the actual problem). *that's* why we've 
solved everything possible in 2.0-line.

> Why can't these changes just be used in the 
> upcoming alpha/beta releases and totally be implemented by the time they
> move to the next stable release. 

Wasn't thought about earlier, just as said, however, I feel really sad when we 
*move*back* that far, since I feel not happy in upgrading to the next apache 
ebuilds on the servers I do administrate, and, in fact, do a downgrade, 
because we at least move back with the configuration *and* (most probably) 
drop LFS-support as well. That'd be hell for me. 
And that's why I proposed to maintain the 2.1-line of apache httpd including 
all current features by now - just(!) in case, everyone really *wants* that 
we shall revert those improvements.

> Asking people to suddenly change midway 
> through is a major pain. If they knew that these kinds of changes were
> going to happen in >2.0.x, then it would be easier for them to manage.

we put a blocker into the depends, so, that users have to unmerge there 
already installed apache before doing an upgrade. My proposal *now* would 
even be, to block actual apache{1,2} installations in pkg_config() that still 
have old configuration files in /etc/apache{,2} around.
So, the user is enforced to have a look at it when having done the upgrade.

src_config() {
    if test -e ${APACHE_CONFDIR}; then
        einfo "${Place_here_the_info_text_and_URL}"

        die "Old configuratioin files detected. Please remove them \
             before upgrading to new apache."
    fi
}

However, I know, that not all ppl would like such a behavior anyway. But doing 
everything automatically isn't just the best option. For this, the old 
configuration has been just *too* crappy to realize auto adaption of of the 
old configuration data into the new layout.

Best regards,
Christian Parpart.

-- 
Netiquette: http://www.ietf.org/rfc/rfc1855.txt
 17:09:51 up 28 days,  6:16,  0 users,  load average: 0.27, 0.42, 0.42

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Christian Parpart]

[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

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, so, that I don't have to live with the
> > old shitty behavior again.
> >
> > Seriousely, why did we put all our power into those improvements when
> > we're now about to revert mostly everything?
>
> I believe that most issues are with the new configuration setup. What
> about checking for the old configuration format and in that case
> providing the old configuration setup. If there is no old format (or
> allready a working new format config file) use the new config system.

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, someone emerged it (though, don't have 2.0.x installed), is 
there be a way to get subversion with +apache2 useflag installed? apache-2.1 
needs latest apr/apr-util's, I just hope that this wouldn't crash in any way.

Cya,
Christian Parpart.

-- 
Netiquette: http://www.ietf.org/rfc/rfc1855.txt
 17:23:03 up 28 days,  6:29,  0 users,  load average: 0.26, 0.31, 0.34

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 4697 bytes --]

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, that I don't have to live with the old
>>>shitty behavior again.
>>>
>>>Seriousely, why did we put all our power into those improvements when
>>>we're now about to revert mostly everything?
>>
>>Because they seriously hork people's installations in some cases and cause
>>lots of frustration. The improvements seem great, but they need to *work*
>>out of the box for most situations which this doesn't appear to be doing.
>>Testing is supposed to be for things that work and just need tweaking, not
>>something that works for most cases and breaks other people's systems. For
>>one, make your eclass backwards compatible so that mod plugins are easier
>>to maintain. You're not reverting if you're saving a lot of people some
>>pain. 
> 
> 
>>Why do you have to push all these improvements on the current stable 
>>line of apache (2.0.x) ? 
> 
> 
> I once read stuart's posting far along ago about needing help in apache herd. 
> So I came in (and others). So we planned what needs to be solved as reported 
> (tons of items were in bugzilla before), and what needs to be done to improve 
> maintainship as well as client/hostadmin side configuration and workflow.
> So we came up to the current feature set we currently have. And I'm really 
> happy w/ our fixes and (far more) about the improvements we made.
> 
> Apache httpd 2.2-line isn't out there yet, so this wasn't an option at all 
> (just once AFAIK and not related to the actual problem). *that's* why we've 
> solved everything possible in 2.0-line.

Thats understandable, but there needs to be a defined path to make this kind of
change. It needs to have a slow transition to the better layout instead of a
quick *BAM* change that everyone has to deal with. Please find a migration plan
so this goes smoother.

>>Why can't these changes just be used in the 
>>upcoming alpha/beta releases and totally be implemented by the time they
>>move to the next stable release. 
> 
> 
> Wasn't thought about earlier, just as said, however, I feel really sad when we 
> *move*back* that far, since I feel not happy in upgrading to the next apache 
> ebuilds on the servers I do administrate, and, in fact, do a downgrade, 
> because we at least move back with the configuration *and* (most probably) 
> drop LFS-support as well. That'd be hell for me. 
> And that's why I proposed to maintain the 2.1-line of apache httpd including 
> all current features by now - just(!) in case, everyone really *wants* that 
> we shall revert those improvements.

Then make the eclass backwards compatible. You're forcing people to use the new
layout when they may not want it. Certainly the eclass can be modified so that a
useflag or something could be used to define which layout to use. After a
certain amount of time, we can deprecate the old layout.

>>Asking people to suddenly change midway 
>>through is a major pain. If they knew that these kinds of changes were
>>going to happen in >2.0.x, then it would be easier for them to manage.
> 
> 
> we put a blocker into the depends, so, that users have to unmerge there 
> already installed apache before doing an upgrade. My proposal *now* would 
> even be, to block actual apache{1,2} installations in pkg_config() that still 
> have old configuration files in /etc/apache{,2} around.
> So, the user is enforced to have a look at it when having done the upgrade.
> 
> src_config() {
>     if test -e ${APACHE_CONFDIR}; then
>         einfo "${Place_here_the_info_text_and_URL}"
> 
>         die "Old configuratioin files detected. Please remove them \
>              before upgrading to new apache."
>     fi
> }

That will help some but may cause other problems.

> However, I know, that not all ppl would like such a behavior anyway. But doing 
> everything automatically isn't just the best option. For this, the old 
> configuration has been just *too* crappy to realize auto adaption of of the 
> old configuration data into the new layout.

Please make this change backwards compatible before putting in ~, thats all I
ask. Its crazy to do this kind of a change without making any part of it
backwards compatible for at least a certain amount of time.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operational Manager

---
Public GPG key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

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

[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/apache2/httpd.conf
# AddDefaultCharset ISO-8859-1
AddDefaultCharset utf8
CharsetDefault utf8
CharsetSourceEnc utf8

maybe adding a USE flag "utf8" that if enabled change run sed on the
config files .

If it's not viable please say me so I'll avoid to put this onto the
production server in next days ;)

-- 
gentoo-dev@gentoo.org mailing list

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

[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 the next stable release. Asking people
> to suddenly change midway through is a major pain. If they knew that these kinds
> of changes were going to happen in >2.0.x, then it would be easier for them to
> manage.

Actually, I think it's a better time to make major changes in ebuild
handling when there aren't major changes in source code. It's easier to
isolate problems.

Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCZtn0XVaO67S1rtsRAsQaAKDpmHZ8DKccrgD7IkUwxXWKvwrNwQCeKxis
M8AnWWRto+owGpNRUXNXGXc=
=jXx3
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

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, someone emerged it (though, don't have 2.0.x
> installed), is there be a way to get subversion with +apache2 useflag
> installed? apache-2.1 needs latest apr/apr-util's, I just hope that
> this wouldn't crash in any way.

The subversion people kind of live on the bleeding edge. I'm quite sure 
that they will support the newest apr/apr-util. I do know for certain 
that they support apr-1.0.0.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]