Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask
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: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpipW7vyKqQF.pgp Description: PGP signature
Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask
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 pgpFGxPPtrag7.pgp Description: PGP signature
Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask
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: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpBLal7h8tJG.pgp Description: PGP signature
Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask
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
pgpmQFpwIcRsk.pgp
Description: PGP signature
Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask
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 pgpakx01jaFGI.pgp Description: PGP signature
Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask
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 [EMAIL PROTECTED]
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
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask
-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
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.nethttp://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 pgpWUDN7o2VTk.pgp Description: PGP signature
Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask
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: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp54TkAdWEZ3.pgp Description: PGP signature
Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask
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
