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

[Lance Albertson]

Christian Parpart wrote:
> 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.

Thats understandable, but there needs to be a defined path to make this kind of
change. It needs to have a slow transition to the better layout instead of a
quick *BAM* change that everyone has to deal with. Please find a migration plan
so this goes smoother.

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

Then make the eclass backwards compatible. You're forcing people to use the new
layout when they may not want it. Certainly the eclass can be modified so that a
useflag or something could be used to define which layout to use. After a
certain amount of time, we can deprecate the old layout.

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

That will help some but may cause other problems.

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

Please make this change backwards compatible before putting in ~, thats all I
ask. Its crazy to do this kind of a change without making any part of it
backwards compatible for at least a certain amount of time.

-- 
Lance Albertson <ramereth@g.o>
Gentoo Infrastructure | Operational Manager

---
Public GPG key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net