Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 89885 - Stabilising net-www/apache & co.
Summary: Stabilising net-www/apache & co.
Status: RESOLVED DUPLICATE of bug 76457
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Server (show other bugs)
Hardware: All All
: High major (vote)
Assignee: Apache Team - Bugzilla Reports
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 60438
  Show dependency tree
 
Reported: 2005-04-20 20:50 UTC by Elfyn McBratney (beu) (RETIRED)
Modified: 2005-09-17 18:24 UTC (History)
19 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-04-20 20:50:46 UTC
Hi folks,

Due to the high number of bugs and breakages in testing, I will be putting the updated apache ebuilds back into package.mask until the related bugs are fixed.

I've compiled a list below of ebuilds which use the new apache stuff (apache-module.eclass and depend.apache.eclass), however this may be slightly wrong - if you've been using said eclasses and/or install into the new apache 1.x/2.x layouts, please package.mask those ebuilds.

Once all ebuilds that are using the new apache stuff have been hard-masked, the apache packages themselves will follow.

Thanks and apologies for all the hassle, mess, <insert painful memory here>.

sys-power/apcupsd-3.10.17
app-admin/webalizer-2.01.10-r7
app-admin/webalizer-2.01.10-r8
dev-ruby/mod_ruby-1.2.4-r1
dev-ruby/mod_ruby-1.2.4-r2
www-servers/skunkweb-3.4.0-r1
www-apache/mod_macro-1.1.2
www-apache/mod_macro-1.1.6
www-apache/mod_umask-0.1.0
www-apache/mod_tcl-1.0-r1
www-apache/mod_jk-1.2.10
www-apache/mod_csv-0.0.1
www-apache/mod_chroot-0.4
www-apache/mod_backhand-1.2.2
www-apache/mod_lisp-2.33-r1
www-apache/mod_lisp-1.1
www-apache/mod_lisp-2.42
www-apache/mod_mono-1.0.6-r1
www-apache/mod_mono-1.0.5-r1
www-apache/mod_gnutls-0.1.1-r1
www-apache/mod_gnutls-0.1.1
www-apache/mod_gnutls-0.1.0
www-apache/mod_diagnostics-0.0.1
www-apache/mod_dav_svn-1.1.3-r1
www-apache/mod_dav_svn-1.1.3
www-apache/mod_dav_svn-1.1.2
www-apache/mod_dav_svn-1.1.1
www-apache/mod_proxy_html-2.4.3
dev-python/mod_python-3.1.4
dev-python/mod_python-2.7.11
net-analyzer/nagios-core-2.0b_p1
net-analyzer/nagios-core-1.2-r4
net-analyzer/nagios-core-2.0b_p2
gnustep-libs/gsweb-1.1.1_pre20050312
net-mail/mailman-2.1.5-r3
net-mail/mailman-2.1.6_beta1-r1
net-mail/mailman-2.1.6_beta1
net-mail/mailman-2.1.5-r5
net-mail/mailman-2.1.5-r4
www-apps/twiki/twiki-20040902-r1
dev-util/subversion/subversion-1.1.3-r1
dev-util/subversion/subversion-1.1.1-r3
dev-php/mod_php/mod_php-5.0.2-r1
dev-php/mod_php/mod_php-5.0.3-r2
dev-php/mod_php/mod_php-4.3.11-r1
dev-php/mod_php/mod_php-5.0.3-r1
dev-php/mod_php/mod_php-4.3.10-r1
net-fs/intersync-0.9.5
net-fs/intersync-0.9.5_p2
net-www/mod_loopback-1.04-r1
net-www/mod_loopback-2.01-r1
net-www/mod_auth_pgsql-2.0.2-r2
net-www/mod_auth_pgsql-0.9.12-r1
net-www/mod_bandwidth-2.0.5-r1
net-www/mod_encoding-20021209-r1
net-www/mod_watch-4.03-r1
net-www/mod_watch-3.18-r1
net-www/mod_auth_external-2.2.9
net-www/mod_auth_external-2.1.19
net-www/mod_auth_external-2.2.7-r1
net-www/mod_scgi-1.2
net-www/mod_roaming-2.0.0-r1
net-www/mod_roaming-1.0.2
net-www/mod_bwshare-0.1.3
net-www/mod_bw-0.6
net-www/mod_bw-0.5_rc1
net-www/mod_bw-0.5
net-www/mod_ftpd-0.13.0
net-www/mod_auth_ldap-2.4.2-r1
net-www/mod_auth_ldap-3.3
net-www/mod_ssl-2.8.22-r1
net-www/mod_ldap_userdir-1.1.5
net-www/mod_ldap_userdir-1.1.4-r1
net-www/mod_auth_kerb-4.11-r1
net-www/mod_auth_kerb-5.0_rc6
net-www/mod_limitipconn-0.04
net-www/mod_limitipconn-0.22-r1
net-www/mod_layout-4.0.1a-r1
net-www/mod_layout/mod_layout-3.2.1-r1
net-www/mod_transform-0.6.0
net-www/mod_xslt-1.0.5a-r1
net-www/mod_xslt-2.0.4
net-www/mod_gzip-1.3.26.1a-r2
net-www/mod_mp3-0.40-r1
net-www/mod_injection-0.3.1-r1
net-www/mod_random-1.4-r1
net-www/mod_random-2.0-r1
net-www/mod_vdbh-1.0.3-r1
net-www/mod_throttle-3.1.2-r2
net-www/mod_fastcgi-2.4.2-r1
net-www/mod_auth_mysql-2.8.1
net-www/mod_auth_pam-1.1.1-r1
net-www/mod_log_sql-1.100
net-www/mod_pcgi2-2.0.2
net-www/mod_dav-1.0.3-r3
net-www/mod_security-1.8.6
net-www/mod_security-1.8.7_rc2
net-www/mod_security-1.8.7
Comment 1 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-04-20 20:55:04 UTC
Forgot to mention: please keep all the masks in one block so it's easier to manage/users to pinpoint.  Thanks.
Comment 2 Donnie Berkholz (RETIRED) gentoo-dev 2005-04-20 22:31:13 UTC
So, this will do a great job of rebreaking things for everyone who's already merged the new stuff?
Comment 3 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-04-20 22:45:37 UTC
Donnie, if you have a better 'solution', I'm all ears.  Otherwise I can see the issues that brought this bug into existence being with until we go stable ..
Comment 4 Benedikt Böhm (RETIRED) gentoo-dev 2005-04-20 23:11:56 UTC
i agree with donnie, and will not support this change... i already updated all metadata.xml's

i will jump in again when we got sane...
Comment 5 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-04-20 23:19:02 UTC
So it's acceptable to leave stuff hosed ?  This stuff is broken badly, testing is mashed wrt apache, users' machines are getting hosed (and the users are being ignored); I've lost count of the number of users who have come into #gentoo or #gentoo-apache nearly in tears because apache updates have caused major grief.

And, personally, I'm sick of personally being blamed for all this crap.  This stuff either needs to go stable now or go into package.mask !

Folks, please hold off on hard-masking.
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2005-04-20 23:50:06 UTC
My strictly personal opinion is that this should be made stable ASAP and the still non-compliant things should be masked accordingly. Older versions should be left in portage until the rest of the things gets fixed so that people can continue using Gentoo with the features they were used to so far. If absolutely necessary, security fixes should be backported to older versions until this is finished. 

My view is that there would never have been such a mess if Apache devs and devs of major Apache related stuff had been able to coordinate better. But after all of this has started to get somewhere recently (at least mod_php has become compliant :p) this seems as a major step back to me and will do more damage then it is worth.  

If you wanted to put it back into package.mask, this should have been done in some two weeks after this whole mess begun and users started screaming but not after more than two months, IIRC. This will screw a lot of machines. Downgrading of this stuff is genuine PITA. There will be _tons_ of bug reports once this _huge_ list gets masked again.

>testing is mashed wrt apache

Right, as I wrote above - this whole thing _desperately_ lacks coordination. You mask apache and this is in no way reflected in mod_php ebuild, pardon me but you   can
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2005-04-20 23:50:06 UTC
My strictly personal opinion is that this should be made stable ASAP and the still non-compliant things should be masked accordingly. Older versions should be left in portage until the rest of the things gets fixed so that people can continue using Gentoo with the features they were used to so far. If absolutely necessary, security fixes should be backported to older versions until this is finished. 

My view is that there would never have been such a mess if Apache devs and devs of major Apache related stuff had been able to coordinate better. But after all of this has started to get somewhere recently (at least mod_php has become compliant :p) this seems as a major step back to me and will do more damage then it is worth.  

If you wanted to put it back into package.mask, this should have been done in some two weeks after this whole mess begun and users started screaming but not after more than two months, IIRC. This will screw a lot of machines. Downgrading of this stuff is genuine PITA. There will be _tons_ of bug reports once this _huge_ list gets masked again.

>testing is mashed wrt apache

Right, as I wrote above - this whole thing _desperately_ lacks coordination. You mask apache and this is in no way reflected in mod_php ebuild, pardon me but you   can´t just play on your own sand here. Is it really so hard to cooperate on this? Is there anyone actually coordinationg the whole apache overhaul? If there is, I have not noticed yet and that means that person failed miserably.

Also - it was not one of the smartest ideas to combine this with overhaul to other packages (like PEAR moving out of mod_php) to contribute even more to this mess. 

Just my $0.02 :/
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2005-04-20 23:56:24 UTC
P.S. If this gets masked anaway (seems that many devs will disagree), there should be _really good_ docs for users how to deal with this situation BEFORE it gets masked. NOT after. I repeat - NOT after. Bugzilla is not a good place to deal with this.
Comment 9 Benedikt Böhm (RETIRED) gentoo-dev 2005-04-21 01:13:24 UTC
i agree... better put it stable asap, and fix the mess (personally, i don't know where the mess is, everything is working excellent on my machines)

afaik mod_perl and mod_ruby now work too, after segfaults have been fixed..
Comment 10 Jakub Moc (RETIRED) gentoo-dev 2005-04-21 01:28:16 UTC
Comment #8: Well, IMHO the whole mess _now_ mostly stems out of the fact that it is not stable yet. I think it
Comment 11 Jakub Moc (RETIRED) gentoo-dev 2005-04-21 01:28:16 UTC
Comment #8: Well, IMHO the whole mess _now_ mostly stems out of the fact that it is not stable yet. I think it´s maily related to those uncoordinated version moves/bumps and to the fact the you just _have to_ get lost in this inevitably, sooner or later. Too many people involved, too many changes, too much burden wrt  backwards compatibility. 

So once this moves to stable, you devs could care about real issues and not about whether this new version should install modules into /usr/lib/apache2-extramodules/ or /usr/lib/apache2/modules/.

So what I would suggest:

- No more dual version bumps (i.e., for both old and new apache layout)
- Packages with old layout maintained only for security issues and only until the remaining few bits are OK.
- Once everything is compliant, prune those old-layout packages from portage really fast. The sooner, the better.

Does this make sense?

Comment 12 Benedikt Böhm (RETIRED) gentoo-dev 2005-04-21 01:45:12 UTC
> Does this make sense?

imo this was the plan until the idea of putting everything in p.mask
Comment 13 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-04-21 01:57:13 UTC
This was the idea, before the unmask - to be done as soon as possible (after the unmask) .. it's been nearly three months since then, that's why I'm so desperate. :)
Comment 14 Jakub Moc (RETIRED) gentoo-dev 2005-04-21 02:07:22 UTC
Comment #10: LOL, you made my day. :-) But well, this is not such fun after all. Lots of users are really pissed off and the move suggested in this bug would be really the last straw for many of them. 

I have gone through the downgrade process on one machine and I say I would never do it again unless the damned thing segfaulted on me every few minutes. After all, as you said, the new "unstable" Apache works like a champ for me too. I would really not like to do cycle thru upgrade/downgrade for next few weeks as many users would probably have to if this is masked. 

Comment #11: Well, so what
Comment 15 Jakub Moc (RETIRED) gentoo-dev 2005-04-21 02:07:22 UTC
Comment #10: LOL, you made my day. :-) But well, this is not such fun after all. Lots of users are really pissed off and the move suggested in this bug would be really the last straw for many of them. 

I have gone through the downgrade process on one machine and I say I would never do it again unless the damned thing segfaulted on me every few minutes. After all, as you said, the new "unstable" Apache works like a champ for me too. I would really not like to do cycle thru upgrade/downgrade for next few weeks as many users would probably have to if this is masked. 

Comment #11: Well, so what´s the problem? How´s Bug 77551 going? What´s the status of 77564? 

If these are two only two major things holding this back, then it makes no sense to me to p.mask this whole bunch. The latest mod_perl does not segfault here. I don´t use mod_ruby, so I can´t tell you anything about that. Are there any other important pieces missing? 

Meanwhile, I´d suggest cleaning out all possible old version where the arches status allows to (just looked at mod_php and apache and there are a few not needed any more).

Don´t do even more desperate steps in a desperate situation, it will just make things worse. A lot of bugs lately are related only to this new/old apache confusion, not that these new versions are crashing on people. Wouldn´t it be better to get rid of those and focus on real work?
Comment 16 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-04-21 02:24:34 UTC
mod_perl and mod_ruby are not the only problems, see http://tinyurl.com/9kqnz for a long overview of the current bugs (disclaimer: some are closed) .. 
Comment 17 Paul de Vrieze (RETIRED) gentoo-dev 2005-04-21 05:57:29 UTC
Can't the eclasses be changed. It would be a lot easier than changing my packages twice to stop supporting these eclasses and then to support them again. Alternatively it would be acceptable if the "correct" eclasses would get a different name. My subversion packages use very little of the eclasses, and just use them to get the correct locations. If you decide the "correct" location changed. Just change the eclass (that was the whole point of the eclass in the first place).
Comment 18 Lance Albertson (RETIRED) gentoo-dev 2005-04-22 04:23:32 UTC
I concurr with pauldv. The biggest problem is the fact that old style ebuilds couldn't use the new eclass because it wasn't backwards compatible. Then we dont' have to force the issue either way to people. I propose the eclass be updated so that either a useflag or other means lets the user choose which layout style to use.
Comment 19 Christian Parpart (RETIRED) gentoo-dev 2005-04-22 05:16:53 UTC
((i'm getting 'em twice. but thanks :p))
Comment 20 Christian Parpart (RETIRED) gentoo-dev 2005-04-22 05:37:10 UTC
after having read the whole thread..... huh... well....

the apache eclass(es) should *not* support both config layouts because this is just UNmaintainable, sorry, but that it is. A apache-module-v1.eclass and apache-module-v2.eclass (same for depend.apache.eclass) would maybe hide this problem. however.

And yeah, if anyone of you really wanna push the improvements - we really worked hard on - back to the old crappy thing, yeah, just go ahead, but "I will not support this", and though will join Hollow and others.

beu; no, I'm NOT against you, I just do think, that this is not the right way, and when you're following the lists/forums/bugzilla, you might have seen, that I was hardly trying to push us forward.

p.s.: being not available actuall doesn't mean I'm not interested in at all - I'm just enforced to stay at work 247 for some weeks :(

thanks.
Comment 21 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-04-22 14:49:36 UTC
I don't want anyone to stop doing all the great work they have been on Apache (this is you Hollow and trapni and others !) because of what I've done.  But we all have to realise how much damage these updates have done (not looking to blame anyone here).

These updates change the 'ABI', the paths where the apache installation is located, etc., all in one lump.  Can we do anything to lessen the load ?  Symlinks or something to try and make old and new live together ?  Anything that makes upgrading and such easier ?

Apologies for the noise to all the people CC'd, but since you all have packages related to/that work with Apache, now would be a good time to find out your opinions..
Comment 22 Christian Parpart (RETIRED) gentoo-dev 2005-04-23 04:02:16 UTC
we should prevent the new apache httpd to get installed when there are still old configuration files found on the local host.

pkg_config() {
    if find_old_config; then
        enotice URL to the nice info page
        die we refuse to get built, because old config files found on same host.
    fi
}

this could be added to the depend.apache.eclass, I suppose :-)
Comment 23 Lance Albertson (RETIRED) gentoo-dev 2005-04-23 19:58:30 UTC
How is it unmaintainable (give straight facts) for having an eclass do both layouts? What type of issues arise from doing that? And if there are good reasons, how are we supposed to distinguish any module ebuild we make to using either the old or new layout? I'm still not seeing the logic of pushing this so hard w/o having a backwards compatibilty plan. You're asking a *bunch* of people to change a bunch of stuff when they upgrade. While its a good change, it needs to be smoother.

What happens if one week after we push this stable and most people haven't had time to test the new layout and a security bump happens? What do all those people still using the old layout do? Are they forced into upgrading into the new layout potentially creating a lot of headache, or will there be some kind of ebuild just for them? That is one situation I can foresee happening. 
Comment 24 Donnie Berkholz (RETIRED) gentoo-dev 2005-04-24 01:15:28 UTC
I've done similar things while changing the xorg layouts. For example, if -r1 was "standard" and -r2 was a major ebuild change, a security bump would result in an -r3 "standard" and -r4 with the major change.

It seemed to work alright.
Comment 25 Greg Surbey 2005-05-03 08:17:34 UTC
Please remember to fix bug 91313 also :-)
Comment 26 Lance Albertson (RETIRED) gentoo-dev 2005-05-05 08:54:30 UTC
Any update to why backwards compatability is unmaintainable facts-wise? I'd like to know specific examples of this.
Comment 27 Michael Stewart (vericgar) (RETIRED) gentoo-dev 2005-09-17 18:24:35 UTC
Let's keep this all under the original tracker bug

*** This bug has been marked as a duplicate of 76457 ***