Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

[Christian Parpart <trapni@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3754 bytes --]

On Wednesday 20 April 2005 2:14 pm, Lance Albertson wrote:
> Christian Parpart wrote:
> > And yeah, I disagree to a move-back, too!! I'm most likely not to support
> > this in any kind, instead, I'd be willing in pushing p.mask'ed apache
> > httpd 2.1 into the tree, so, that I don't have to live with the old
> > shitty behavior again.
> >
> > Seriousely, why did we put all our power into those improvements when
> > we're now about to revert mostly everything?
>
> Because they seriously hork people's installations in some cases and cause
> lots of frustration. The improvements seem great, but they need to *work*
> out of the box for most situations which this doesn't appear to be doing.
> Testing is supposed to be for things that work and just need tweaking, not
> something that works for most cases and breaks other people's systems. For
> one, make your eclass backwards compatible so that mod plugins are easier
> to maintain. You're not reverting if you're saving a lot of people some
> pain. 

> Why do you have to push all these improvements on the current stable 
> line of apache (2.0.x) ? 

I once read stuart's posting far along ago about needing help in apache herd. 
So I came in (and others). So we planned what needs to be solved as reported 
(tons of items were in bugzilla before), and what needs to be done to improve 
maintainship as well as client/hostadmin side configuration and workflow.
So we came up to the current feature set we currently have. And I'm really 
happy w/ our fixes and (far more) about the improvements we made.

Apache httpd 2.2-line isn't out there yet, so this wasn't an option at all 
(just once AFAIK and not related to the actual problem). *that's* why we've 
solved everything possible in 2.0-line.

> Why can't these changes just be used in the 
> upcoming alpha/beta releases and totally be implemented by the time they
> move to the next stable release. 

Wasn't thought about earlier, just as said, however, I feel really sad when we 
*move*back* that far, since I feel not happy in upgrading to the next apache 
ebuilds on the servers I do administrate, and, in fact, do a downgrade, 
because we at least move back with the configuration *and* (most probably) 
drop LFS-support as well. That'd be hell for me. 
And that's why I proposed to maintain the 2.1-line of apache httpd including 
all current features by now - just(!) in case, everyone really *wants* that 
we shall revert those improvements.

> Asking people to suddenly change midway 
> through is a major pain. If they knew that these kinds of changes were
> going to happen in >2.0.x, then it would be easier for them to manage.

we put a blocker into the depends, so, that users have to unmerge there 
already installed apache before doing an upgrade. My proposal *now* would 
even be, to block actual apache{1,2} installations in pkg_config() that still 
have old configuration files in /etc/apache{,2} around.
So, the user is enforced to have a look at it when having done the upgrade.

src_config() {
    if test -e ${APACHE_CONFDIR}; then
        einfo "${Place_here_the_info_text_and_URL}"

        die "Old configuratioin files detected. Please remove them \
             before upgrading to new apache."
    fi
}

However, I know, that not all ppl would like such a behavior anyway. But doing 
everything automatically isn't just the best option. For this, the old 
configuration has been just *too* crappy to realize auto adaption of of the 
old configuration data into the new layout.

Best regards,
Christian Parpart.

-- 
Netiquette: http://www.ietf.org/rfc/rfc1855.txt
 17:09:51 up 28 days,  6:16,  0 users,  load average: 0.27, 0.42, 0.42

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]