[arch-general] apache 2.4
I'm just curious as to why we're still on apache-2.2, at one point I think I assumed it was a php thing, but php-5.5 got lauched a bit ago and I can think of at least one php application I tried to run which wouldn't work on it, so that's probably not it. -- Caleb Cushing http://xenoterracide.com Calendar: https://www.google.com/calendar/embed?src=xenoterracide%40gmail.com&ctz=America/Chicago
On 2013-11-19 22:21:13 -0600, Caleb Cushing wrote:
I'm just curious as to why we're still on apache-2.2, at one point I think I assumed it was a php thing, but php-5.5 got lauched a bit ago and I can think of at least one php application I tried to run which wouldn't work on it, so that's probably not it.
From Jan de Groot[0]:
Just dropping the default choice of DNS resolving utilities because you don't like a new version of a server and its build system is I don't like Apache 2.4 either, but instead of dropping Apache from the repos and replacing it with nginx I chose to keep 2.2.x and support that instead.
0: https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024690.ht...
On Wed, Nov 20, 2013 at 01:46:55PM +0800, Chris Down wrote:
On 2013-11-19 22:21:13 -0600, Caleb Cushing wrote:
I'm just curious as to why we're still on apache-2.2, at one point I think I assumed it was a php thing, but php-5.5 got lauched a bit ago and I can think of at least one php application I tried to run which wouldn't work on it, so that's probably not it.
From Jan de Groot[0]:
Just dropping the default choice of DNS resolving utilities because you don't like a new version of a server and its build system is I don't like Apache 2.4 either, but instead of dropping Apache from the repos and replacing it with nginx I chose to keep 2.2.x and support that instead.
0: https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024690.ht...
In a few months we are going to be getting RHEL 7, probably in the first quarter of 2014. They are branching that release off Fedora 19. I know this much may not concern you people, but they are going to have httpd 2.4. I really think that the argument that is presented there is quite awful. If anything we should have an apache22 package to let people keep using that version of apache, and then have our apache package be the very latest version (possibly have it provide apache24). Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
Hi, Am 20.11.2013 07:28, schrieb William Giokas:
I really think that the argument that is presented there is quite awful.
Yes, I think so, too. A rolling release shouldn't hold back new versions for months because a specific Maintainer doesn't like it for quite subjective reasons.
If anything we should have an apache22 package to let people keep using that version of apache, and then have our apache package be the very latest version (possibly have it provide apache24).
+1 Best regards, Karol Babioch
Op 21 nov. 2013 12:02 schreef "Karol Babioch" <karol@babioch.de> het volgende:
Hi,
Am 20.11.2013 07:28, schrieb William Giokas:
I really think that the argument that is presented there is quite awful.
Yes, I think so, too. A rolling release shouldn't hold back new versions for months because a specific Maintainer doesn't like it for quite subjective reasons.
Actually, the fact if $dev wants to work on it or not is entirely subjective imho. On the other hand; anyone can post a PKGBUILD on the AUR of course. Just remember that the devs are volunteers. mvg, Guus
On 11/21/13 at 01:41pm, Guus Snijders wrote:
Op 21 nov. 2013 12:02 schreef "Karol Babioch" <karol@babioch.de> het volgende:
Hi,
Am 20.11.2013 07:28, schrieb William Giokas:
I really think that the argument that is presented there is quite awful.
Yes, I think so, too. A rolling release shouldn't hold back new versions for months because a specific Maintainer doesn't like it for quite subjective reasons.
Actually, the fact if $dev wants to work on it or not is entirely subjective imho. On the other hand; anyone can post a PKGBUILD on the AUR of course.
Just remember that the devs are volunteers.
mvg, Guus
Apache24 is already in AUR. https://aur.archlinux.org/packages/apache24/ -- Jelle van der Waa
On 11/20/2013 05:21 AM, Caleb Cushing wrote:
I'm just curious as to why we're still on apache-2.2, at one point I think I assumed it was a php thing, but php-5.5 got lauched a bit ago and I can think of at least one php application I tried to run which wouldn't work on it, so that's probably not it.
I've posted few patches back in July for Apache 2.4 enablement, but I got no attention from JGC at all. Note that php patch isn't correct one - php 5.5 seems to explicitly need zts enabled using --enable-maintainer-zts in order to get PHP5 apache module to work with Apache 2.4. https://mailman.archlinux.org/pipermail/arch-general/2013-July/033772.html
Hi, This situation with apache-2.4 reminds me recent saga with libxml2 update. libxml2 was marked out-of-date for 9 months and maintainer ignored requests about upgrading the package. The only explanation was "if maintainer does not upgrade the package there must be a good reason for it - new version probably breaks other apps". But it end up that the new libxml2 package did not break anyone and upgrade was very simple - it was just a version bump and no dependencies rebuild was needed. I made a conclusion that maintainer just lost interest in supporting libxml2. Could it be the same situation with apache-2.2 package? If the maintainer lost interest would it be better to drop Apache to 'community' repo where it has higher chance to be upgraded? IMHO it is shame for Arch to keep old versions of software without clear explanation, 2.4.1 was released almost 2 years ago!
On Mon, 2 Dec 2013 11:32:13 -0800 Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
Hi,
This situation with apache-2.4 reminds me recent saga with libxml2 update. libxml2 was marked out-of-date for 9 months and maintainer ignored requests about upgrading the package. The only explanation was "if maintainer does not upgrade the package there must be a good reason for it - new version probably breaks other apps". But it end up that the new libxml2 package did not break anyone and upgrade was very simple - it was just a version bump and no dependencies rebuild was needed. I made a conclusion that maintainer just lost interest in supporting libxml2.
What exactly are you complaining about? Apache 2.2 is still supported upstream (2.2.26 was released on 11/16/2013 -- two weeks ago). Apache 2.4 is just another branch. So why is apache-2.2 old?
Could it be the same situation with apache-2.2 package? If the maintainer lost interest would it be better to drop Apache to 'community' repo where it has higher chance to be upgraded? IMHO it is shame for Arch to keep old versions of software without clear explanation, 2.4.1 was released almost 2 years ago!
Apache 2.2.15 was pushed in 07/2013. This situation hardly qualifies as "lost interest". If you desperately need 2.4.7 and are absolutely sure that it is compatible with 2.2 why not just compile it yourself? Cheers, -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Hi, I don't really care about Apache specifically but I feel the need to chime in. On 12/02/2013 09:06 PM, Leonid Isaev wrote:
On Mon, 2 Dec 2013 11:32:13 -0800 Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
Hi,
This situation with apache-2.4 reminds me recent saga with libxml2 update. libxml2 was marked out-of-date for 9 months and maintainer ignored requests about upgrading the package. The only explanation was "if maintainer does not upgrade the package there must be a good reason for it - new version probably breaks other apps". But it end up that the new libxml2 package did not break anyone and upgrade was very simple - it was just a version bump and no dependencies rebuild was needed. I made a conclusion that maintainer just lost interest in supporting libxml2. What exactly are you complaining about? Apache 2.2 is still supported upstream (2.2.26 was released on 11/16/2013 -- two weeks ago). Apache 2.4 is just another branch. So why is apache-2.2 old?
"We consider the Apache HTTP Server 2.4 release to be the best version of Apache available, and encourage users of 2.2 and all prior versions to upgrade. This 2.2 maintenance release is offered for those unable to upgrade at this time." [1] Because upstream itself says so?
Could it be the same situation with apache-2.2 package? If the maintainer lost interest would it be better to drop Apache to 'community' repo where it has higher chance to be upgraded? IMHO it is shame for Arch to keep old versions of software without clear explanation, 2.4.1 was released almost 2 years ago! Apache 2.2.15 was pushed in 07/2013. This situation hardly qualifies as "lost interest". If you desperately need 2.4.7 and are absolutely sure that it is compatible with 2.2 why not just compile it yourself?
Cheers,
"Arch Linux strives to maintain the latest stable release versions of its software as long as systemic package breakage can be reasonably avoided." [2] I thought Arch strives to be as up-to-date and bleeding edge as possible? So the question is if there is systematic breakage and if not, why there is no Apache 2.4 package available in the official repositories. Sure, people can compile it themselves but why do they have to? [1] https://www.apache.org/dist/httpd/Announcement2.2.html [2] https://wiki.archlinux.org/index.php/Arch_Linux
Apache 2.2.15 was pushed in 07/2013. This situation hardly qualifies as "lost interest". If you desperately need 2.4.7 and are absolutely sure that it is compatible with 2.2 why not just compile it yourself?
We have both Python 2 and Python 3 in official repos. The same could apply to Apache I believe. -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
On Mon, 2 Dec 2013 11:32:13 -0800 Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
Hi,
This situation with apache-2.4 reminds me recent saga with libxml2 update. libxml2 was marked out-of-date for 9 months and maintainer ignored requests about upgrading the package. The only explanation was "if maintainer does not upgrade the package there must be a good reason for it - new version probably breaks other apps". But it end up that the new libxml2 package did not break anyone and upgrade was very simple - it was just a version bump and no dependencies rebuild was needed. I made a conclusion that maintainer just lost interest in supporting libxml2.
What exactly are you complaining about? What I am trying to say is that keeping software up-to-date is one of
Hi On Mon, Dec 2, 2013 at 12:06 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote: the main maintainer's responsibilities. Especially in Arch Linux that "strives to stay bleeding edge, and typically offers the latest stable versions of most software" (quote from https://wiki.archlinux.org/index.php/Arch_Linux).
Apache 2.2 is still supported upstream (2.2.26 was released on 11/16/2013 -- two weeks ago). Apache 2.4 is just another branch. No, it is not "just another branch". 2.4 is the latest stable version recommended by upstream. 2.2 has status of legacy release.
Could it be the same situation with apache-2.2 package? If the maintainer lost interest would it be better to drop Apache to 'community' repo where it has higher chance to be upgraded? IMHO it is shame for Arch to keep old versions of software without clear explanation, 2.4.1 was released almost 2 years ago!
Apache 2.2.15 was pushed in 07/2013. This situation hardly qualifies as "lost interest". If you desperately need 2.4.7 and are absolutely sure that it is compatible with 2.2 why not just compile it yourself?
Cheers, -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On 12/02/2013 04:43 PM, Anatol Pomozov wrote:
What I am trying to say is that keeping software up-to-date is one of the main maintainer's responsibilities. Especially in Arch Linux that "strives to stay bleeding edge, and typically offers the latest stable versions of most software" (quote from https://wiki.archlinux.org/index.php/Arch_Linux).
Re-read "typically offer the latest stable release of MOST software" What any distribution has to do is remain reliable and usable to the installed userbase above all. This apache 2.2/2.4 situation is somewhat of an aberration, but you need to think about this from a logistical/usability standpoint. Think about the sheer number of apache 2.2 installs, some very complex. Forcing a knee-jerk move to 2.4 requires every user with a 2.2 install to set aside the time and resources required to pick through the changelogs, and implement configuration changes to each and every Arch apache 2.2 site in existence, and then to troubleshoot the unintended consequences of the changes. With apache being the supporting software for numerous groupware and e-commerce sites, the economic impact is not trivial. The 2.2->2.4 update represents a "major" update to crucial parts of apache including: o removal of modules mod_authn_default, mod_authz_default, mod_mem_cache o All load balancing moved to individual, self-contained mod_proxy submodules o --> significant changes in authorization configuration <-- o removal of AuthzLDAPAuthoritative, AuthzDBDAuthoritative, etc... o numerous modules and options have been renamed see: http://httpd.apache.org/docs/2.4/upgrading.html Arch is bleeding edge, much to my chagrin at times, but I fully support the conservative approach being taken with regard to apache 2.2/2.4. If you just have to have 2.4 right now, then it is simple to install, go do it. Don't push a whole distribution to jump forward to the latest apache release where there is a real-world downside of breakage to the installed userbase. On 7/9/13 there was a discussion about whether Arch was appropriate for use with servers, see: "[arch-general] Arch Linux on servers?". That is the crux of this issue. Arch, while remaining at the "bleeding edge", must provide sane updates that do not break or destroy critical applications jolting the userbase to implement time-consuming and costly updates. To Arch's credit, they do a darn good job striking a balance, but it is a balance nonetheless between usability, reliability and bleeding-edge. Without reliability and usability for core server applications, a distribution is relegated to being nothing more than a desktop plaything for hobbyists or enthusiasts. For something as fundamental to server operations as apache, Arch should continue to provide 2.2 as the core package while providing 2.4 in testing for an extended period. A clear timeline for the move of 2.4 from testing to core should be developed by reasoned discussion with input from the user base. Once 2.4 moves to core, 2.2 should be maintained in core as (eg. apache22) for so long as support is provided by apache.org. -- David C. Rankin, J.D.,P.E.
On Tue, Dec 03, 2013 at 09:37:19AM -0600, David C. Rankin wrote:
On 12/02/2013 04:43 PM, Anatol Pomozov wrote:
What I am trying to say is that keeping software up-to-date is one of the main maintainer's responsibilities. Especially in Arch Linux that "strives to stay bleeding edge, and typically offers the latest stable versions of most software" (quote from https://wiki.archlinux.org/index.php/Arch_Linux).
Re-read "typically offer the latest stable release of MOST software"
What any distribution has to do is remain reliable and usable to the installed userbase above all. This apache 2.2/2.4 situation is somewhat of an aberration, but you need to think about this from a logistical/usability standpoint. Think about the sheer number of apache 2.2 installs, some very complex. Forcing a knee-jerk move to 2.4 requires every user with a 2.2 install to set aside the time and resources required to pick through the changelogs, and implement configuration changes to each and every Arch apache 2.2 site in existence, and then to troubleshoot the unintended consequences of the changes. With apache being the supporting software for numerous groupware and e-commerce sites, the economic impact is not trivial.
The 2.2->2.4 update represents a "major" update to crucial parts of apache including:
o removal of modules mod_authn_default, mod_authz_default, mod_mem_cache o All load balancing moved to individual, self-contained mod_proxy submodules o --> significant changes in authorization configuration <-- o removal of AuthzLDAPAuthoritative, AuthzDBDAuthoritative, etc... o numerous modules and options have been renamed
see: http://httpd.apache.org/docs/2.4/upgrading.html
Arch is bleeding edge, much to my chagrin at times, but I fully support the conservative approach being taken with regard to apache 2.2/2.4. If you just have to have 2.4 right now, then it is simple to install, go do it. Don't push a whole distribution to jump forward to the latest apache release where there is a real-world downside of breakage to the installed userbase.
On 7/9/13 there was a discussion about whether Arch was appropriate for use with servers, see: "[arch-general] Arch Linux on servers?". That is the crux of this issue. Arch, while remaining at the "bleeding edge", must provide sane updates that do not break or destroy critical applications jolting the userbase to implement time-consuming and costly updates. To Arch's credit, they do a darn good job striking a balance, but it is a balance nonetheless between usability, reliability and bleeding-edge. Without reliability and usability for core server applications, a distribution is relegated to being nothing more than a desktop plaything for hobbyists or enthusiasts.
For something as fundamental to server operations as apache, Arch should continue to provide 2.2 as the core package while providing 2.4 in testing for an extended period. A clear timeline for the move of 2.4 from testing to core should be developed by reasoned discussion with input from the user base. Once 2.4 moves to core, 2.2 should be maintained in core as (eg. apache22) for so long as support is provided by apache.org.
Now this is something I can get behind. Servers are not (or should not) be running [testing] or anything of that nature, and so should not be affected by the changes that going to 2.4 in [testing] would bring. However, people with a testing environment would have a clear upgrade path and the ability to test and give feedback to the Arch packagers and maintainers for issues or other things that happen with 2.4 while it's in [testing], instead of just complaining to upstream or that some AUR package is not working. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
For something as fundamental to server operations as apache, Arch should continue to provide 2.2 as the core package while providing 2.4 in testing for an extended period.
This sounds very Debianish. I haven't seen the same approach for any other package in Arch Linux. Please correct me if I am wrong though. systemd which caused way more serious changes across the whole operating system was introduced very quickly. Apache is not a core component of the system. It's just some daemon, not everyone's using it, and it's independent of the other parts of the system. There may be even two versions of this package in the repo, just like for Python. What I think is we may still provide Apache 2.2, but Apache 2.4 should really be in the repo as soon as possible. -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
Hi, Am 03.12.2013 16:37, schrieb David C. Rankin:
The 2.2->2.4 update represents a "major" update to crucial parts of apache including:
This is exactly the reason why the new version should be provided by Arch itself and not some "third-party" AUR packages.
For something as fundamental to server operations as apache, Arch should continue to provide 2.2 as the core package while providing 2.4 in testing for an extended period. A clear timeline for the move of 2.4 from testing to core should be developed by reasoned discussion with input from the user base. Once 2.4 moves to core, 2.2 should be maintained in core as (eg. apache22) for so long as support is provided by apache.org.
Having used Arch for a couple of years now, this usually is something that gets resolved by an appropriate RFC over on the arch-dev mailing list. I have no problem with there actually being two version of Apache in the repositories for a while, so people get some time to get their installations migrated. Looking at this from the "outside" there seems to be no effort to get this thing started at all. I don't see any technical reasons for this, but at least to me it seems that basically nobody cares ... Best regards, Karol Babioch
On 04/12/13 07:59, Karol Babioch wrote:
Hi,
Am 03.12.2013 16:37, schrieb David C. Rankin:
The 2.2->2.4 update represents a "major" update to crucial parts of apache including:
This is exactly the reason why the new version should be provided by Arch itself and not some "third-party" AUR packages.
For something as fundamental to server operations as apache, Arch should continue to provide 2.2 as the core package while providing 2.4 in testing for an extended period. A clear timeline for the move of 2.4 from testing to core should be developed by reasoned discussion with input from the user base. Once 2.4 moves to core, 2.2 should be maintained in core as (eg. apache22) for so long as support is provided by apache.org.
Having used Arch for a couple of years now, this usually is something that gets resolved by an appropriate RFC over on the arch-dev mailing list. I have no problem with there actually being two version of Apache in the repositories for a while, so people get some time to get their installations migrated. Looking at this from the "outside" there seems to be no effort to get this thing started at all. I don't see any technical reasons for this, but at least to me it seems that basically nobody cares ...
Exactly. AFAIK, we have no-one interested in maintaining apache-2.4. I'm sure we could have apache22 and apache (2.4) otherwise. A
Hi
Exactly. AFAIK, we have no-one interested in maintaining apache-2.4. I'm sure we could have apache22 and apache (2.4) otherwise.
If no-one from core developers wants to maintain this package could you please move apache and modules to community repo? There are TU who will help to maintain this. We already have another popular http server (nginx) that is successfully maintained by community and Apache should be fine there as well.
On 04/12/13 14:49, Anatol Pomozov wrote:
Hi
Exactly. AFAIK, we have no-one interested in maintaining apache-2.4. I'm sure we could have apache22 and apache (2.4) otherwise.
If no-one from core developers wants to maintain this package could you please move apache and modules to community repo? There are TU who will help to maintain this. We already have another popular http server (nginx) that is successfully maintained by community and Apache should be fine there as well.
TUs know how to request this (hint: arch-dev-public...)
participants (13)
-
AK
-
Allan McRae
-
Anatol Pomozov
-
Armin K.
-
Caleb Cushing
-
Chris Down
-
David C. Rankin
-
Guus Snijders
-
Jelle van der Waa
-
Karol Babioch
-
Leonid Isaev
-
Nowaker
-
William Giokas