Gentoo Archives: gentoo-dev

From: Christian Parpart <trapni@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask
Date: Wed, 20 Apr 2005 15:22:41
In Reply to: Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask by Lance Albertson
1 On Wednesday 20 April 2005 2:14 pm, Lance Albertson wrote:
2 > Christian Parpart wrote:
3 > > And yeah, I disagree to a move-back, too!! I'm most likely not to support
4 > > this in any kind, instead, I'd be willing in pushing p.mask'ed apache
5 > > httpd 2.1 into the tree, so, that I don't have to live with the old
6 > > shitty behavior again.
7 > >
8 > > Seriousely, why did we put all our power into those improvements when
9 > > we're now about to revert mostly everything?
10 >
11 > Because they seriously hork people's installations in some cases and cause
12 > lots of frustration. The improvements seem great, but they need to *work*
13 > out of the box for most situations which this doesn't appear to be doing.
14 > Testing is supposed to be for things that work and just need tweaking, not
15 > something that works for most cases and breaks other people's systems. For
16 > one, make your eclass backwards compatible so that mod plugins are easier
17 > to maintain. You're not reverting if you're saving a lot of people some
18 > pain.
20 > Why do you have to push all these improvements on the current stable
21 > line of apache (2.0.x) ?
23 I once read stuart's posting far along ago about needing help in apache herd.
24 So I came in (and others). So we planned what needs to be solved as reported
25 (tons of items were in bugzilla before), and what needs to be done to improve
26 maintainship as well as client/hostadmin side configuration and workflow.
27 So we came up to the current feature set we currently have. And I'm really
28 happy w/ our fixes and (far more) about the improvements we made.
30 Apache httpd 2.2-line isn't out there yet, so this wasn't an option at all
31 (just once AFAIK and not related to the actual problem). *that's* why we've
32 solved everything possible in 2.0-line.
34 > Why can't these changes just be used in the
35 > upcoming alpha/beta releases and totally be implemented by the time they
36 > move to the next stable release.
38 Wasn't thought about earlier, just as said, however, I feel really sad when we
39 *move*back* that far, since I feel not happy in upgrading to the next apache
40 ebuilds on the servers I do administrate, and, in fact, do a downgrade,
41 because we at least move back with the configuration *and* (most probably)
42 drop LFS-support as well. That'd be hell for me.
43 And that's why I proposed to maintain the 2.1-line of apache httpd including
44 all current features by now - just(!) in case, everyone really *wants* that
45 we shall revert those improvements.
47 > Asking people to suddenly change midway
48 > through is a major pain. If they knew that these kinds of changes were
49 > going to happen in >2.0.x, then it would be easier for them to manage.
51 we put a blocker into the depends, so, that users have to unmerge there
52 already installed apache before doing an upgrade. My proposal *now* would
53 even be, to block actual apache{1,2} installations in pkg_config() that still
54 have old configuration files in /etc/apache{,2} around.
55 So, the user is enforced to have a look at it when having done the upgrade.
57 src_config() {
58 if test -e ${APACHE_CONFDIR}; then
59 einfo "${Place_here_the_info_text_and_URL}"
61 die "Old configuratioin files detected. Please remove them \
62 before upgrading to new apache."
63 fi
64 }
66 However, I know, that not all ppl would like such a behavior anyway. But doing
67 everything automatically isn't just the best option. For this, the old
68 configuration has been just *too* crappy to realize auto adaption of of the
69 old configuration data into the new layout.
71 Best regards,
72 Christian Parpart.
74 --
75 Netiquette:
76 17:09:51 up 28 days, 6:16, 0 users, load average: 0.27, 0.42, 0.42