| Summary: | Meta: apache package refresh tracker (Merge 08 Jan 2005, Unmask 27 Feb 2005, Stable 18 Sep 2005??) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michael Stewart (vericgar) (RETIRED) <vericgar> |
| Component: | Current packages | Assignee: | Apache Team - Bugzilla Reports <apache-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | beu, gentoo.bugs.10, gurligebis, marek.wiecek, matteo, pauldv, satya, sbriesen, staff.de, toke, tsabi-gentoo, viktor, wendallc, wjmcqueen, wschlich |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 33371, 50611, 58937, 76460, 77063, 77074, 77455, 77539, 77542, 77547, 77551, 77556, 77562, 77564, 77778, 77781, 77916, 79429, 79430, 79431, 79432, 79434, 79435, 79436, 79437, 79438, 79440, 79443, 79722, 81738, 83445 | ||
| Bug Blocks: | 68026, 77251, 81244, 81796 | ||
|
Description
Michael Stewart (vericgar) (RETIRED)
2005-01-02 16:20:23 UTC
http://dev.gentoo.org/~vericgar/doc/apache-package-refresh.html This is a work-in-progress, but now contains instructions on how to update an ebuild to work with the new eclass. Planned unmask date is Feb 12. I have a little bit of documentation to finish up and then I'm going to send out an announcement. If you have any blockers, please note them here. Thanks! We need to come to a solution re: bug 81738, whether to use NEED_APACHE=x or need_apachex. See that bug for more details. This is a blocker though, because if we have to make those kinds of changes it will be quite a bit of work. Fwiw, I'm not happy that bug 81738 is a blocker - it clearly has no adverse effects wrt the dependency cache, or noticeable slow downs. Perhaps we should worry about once the kde ebuilds have stopped playing such tricks ;-) Bug 81738 is no longer a blocker. We will unmask on 26 Feb unless any more blockers come up. I will send out an announcement in a few hours. Bug 58560 is unrelated to our unmasking. http://dev.gentoo.org/~vericgar/doc/apache-unmask-announce.txt does anyone have any other possible blockers to unmasking? If not, I will send the announcement out, make the changes to package.mask, do a repoman scan on the entire tree (will take a bit of time......), and then commit if nothings broken. I won't be making changes to package.mask for any packages that aren't ours... (mod_php, subversion, etc).. also, I'm not going to touch the mod_dav_svn as pauldv seems to still be implementing it in his subversion ebuilds, so it's up to him if it's split out or not I will be back on IRC at 26-Feb 1700 UTC to do so. Correction: 27-Feb 1700 UTC... blah. Guys, the update instructions tell to use use_apache2. How do I use that with a useflag dependency. I need to conditionally depend on apache2. @vericgar: bug in the doc: it's need_apache{1,2} not use_apache{1,2}
@pauldv: you should use the function `need_apache` which will put apache2 in IUSE, so you can
if use apache2; then foo; else bar; fi
benedikt. That won't work. I eiter use apache 2 or use nothing. I solved it now by just using the variable as defined in the eclass. I have the useflag allready there. maybe i got your problem wrong..!? @benedikt: Yes you did. The apache module for subversion is dependent on whether the apache2 useflag is specified. For this I need to conditionally depend on apache2. Packages that are maintained by the apache herd have been unmasked. The others will need to be unmasked by their maintainers. added bug 83649 for the apcupsd modules.d-file I don't see the mod_jk2 's bug. But it don't build with the new apache, because the libtool file is in another directory (before it was in the apache package, but now it is in the apr package: dev-libs/apr-0.9.6-r2 (/usr/share/apr-0/build/libtool)). I check it's ebuild, but it has too much things to fix, and i can't fix it. I don't know exactly what to do, that i shuolf fill a new bug and somehow depend on this bug, or it should do by this bug's submitter, or this isn't a bug, just i am a lame? So i wrote this here, and please fix it. thanks, tsabi Comment #16 - you should use mod_jk, not mod_jk2 (which in now unsupported and will be removed - Bug 77834) Sorry, if this is under the wrong thread. I will create a new report if needed but the title and description of this report leads me to believe this goes here. Anyways... I just began to install Apache today and found this document. The document is shown to be last updated on 2005-02-26 so I assumed by now that 2.0.15-r4 would be considered new but obviously not. Can an update be made to http://dev.gentoo.org/~vericgar/doc/apache-package-refresh.html so that version numbers are shown in the Apache Path Locations. For example, versions <=2.0.15-r4 refer to old paths and I was told on #gentoo-apache from an OP that versions >= 2.0.15-r5 refer to new paths. So to avoid any possible confusion can an update be to reflect which versions of Apache constitute old and new changes? Thanks. Not necessarily. I'll put a new document in my webspace sometime after our meeting tomorrow to describe any further changes. For now, stable (arch) refers to old-style configs, unstable (~arch) refers to new-style configs. Alright, a little ping: what is the status on this? Seems there is not a lot of activity on this bug and its dependents (except for one, I think). When is this getting to stable? There is a security bug in mod_python (3.1.4) being blocked by this, as well as all the subversion goodies from 1.2, and probably lots of other stuff. Is there anything show-stopper holding new-style from going stable? I've put up a proposed stable announcement at http://dev.gentoo.org/~vericgar/doc/apache-stable-announce.txt that I intend to send out Wednesday if there aren't any issues. As long as you send a reminder message to dev or core on the saturday before I see no reasons not to go ahead. I do want the time to mark stable the proper version of the subversion ebuild though. *** Bug 89885 has been marked as a duplicate of this bug. *** New-style is stable, this can be closed. |