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

On 11/21/13 at 01:41pm, Guus Snijders wrote:

Op 21 nov. 2013 12:02 schreef "Karol Babioch" 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

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!

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 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

On Mon, 2 Dec 2013 11:32:13 -0800 Anatol Pomozov 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 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 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

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

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.