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
Forgot to mention: please keep all the masks in one block so it's easier to manage/users to pinpoint. Thanks.
So, this will do a great job of rebreaking things for everyone who's already merged the new stuff?
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 ..
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...
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.
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
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 :/
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.
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 #8: Well, IMHO the whole mess _now_ mostly stems out of the fact that it is not stable yet. I think it
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?
> Does this make sense? imo this was the plan until the idea of putting everything in p.mask
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 #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 #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?
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) ..
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).
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.
((i'm getting 'em twice. but thanks :p))
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.
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..
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 :-)
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.
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.
Please remember to fix bug 91313 also :-)
Any update to why backwards compatability is unmaintainable facts-wise? I'd like to know specific examples of this.
Let's keep this all under the original tracker bug *** This bug has been marked as a duplicate of 76457 ***
