Gentoo Archives: gentoo-dev

From: Lance Albertson <ramereth@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:35:45
In Reply to: Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask by Christian Parpart
1 Christian Parpart wrote:
2 > On Wednesday 20 April 2005 2:14 pm, Lance Albertson wrote:
3 >
4 >>Christian Parpart wrote:
5 >>
6 >>>And yeah, I disagree to a move-back, too!! I'm most likely not to support
7 >>>this in any kind, instead, I'd be willing in pushing p.mask'ed apache
8 >>>httpd 2.1 into the tree, so, that I don't have to live with the old
9 >>>shitty behavior again.
10 >>>
11 >>>Seriousely, why did we put all our power into those improvements when
12 >>>we're now about to revert mostly everything?
13 >>
14 >>Because they seriously hork people's installations in some cases and cause
15 >>lots of frustration. The improvements seem great, but they need to *work*
16 >>out of the box for most situations which this doesn't appear to be doing.
17 >>Testing is supposed to be for things that work and just need tweaking, not
18 >>something that works for most cases and breaks other people's systems. For
19 >>one, make your eclass backwards compatible so that mod plugins are easier
20 >>to maintain. You're not reverting if you're saving a lot of people some
21 >>pain.
22 >
23 >
24 >>Why do you have to push all these improvements on the current stable
25 >>line of apache (2.0.x) ?
26 >
27 >
28 > I once read stuart's posting far along ago about needing help in apache herd.
29 > So I came in (and others). So we planned what needs to be solved as reported
30 > (tons of items were in bugzilla before), and what needs to be done to improve
31 > maintainship as well as client/hostadmin side configuration and workflow.
32 > So we came up to the current feature set we currently have. And I'm really
33 > happy w/ our fixes and (far more) about the improvements we made.
34 >
35 > Apache httpd 2.2-line isn't out there yet, so this wasn't an option at all
36 > (just once AFAIK and not related to the actual problem). *that's* why we've
37 > solved everything possible in 2.0-line.
39 Thats understandable, but there needs to be a defined path to make this kind of
40 change. It needs to have a slow transition to the better layout instead of a
41 quick *BAM* change that everyone has to deal with. Please find a migration plan
42 so this goes smoother.
44 >>Why can't these changes just be used in the
45 >>upcoming alpha/beta releases and totally be implemented by the time they
46 >>move to the next stable release.
47 >
48 >
49 > Wasn't thought about earlier, just as said, however, I feel really sad when we
50 > *move*back* that far, since I feel not happy in upgrading to the next apache
51 > ebuilds on the servers I do administrate, and, in fact, do a downgrade,
52 > because we at least move back with the configuration *and* (most probably)
53 > drop LFS-support as well. That'd be hell for me.
54 > And that's why I proposed to maintain the 2.1-line of apache httpd including
55 > all current features by now - just(!) in case, everyone really *wants* that
56 > we shall revert those improvements.
58 Then make the eclass backwards compatible. You're forcing people to use the new
59 layout when they may not want it. Certainly the eclass can be modified so that a
60 useflag or something could be used to define which layout to use. After a
61 certain amount of time, we can deprecate the old layout.
63 >>Asking people to suddenly change midway
64 >>through is a major pain. If they knew that these kinds of changes were
65 >>going to happen in >2.0.x, then it would be easier for them to manage.
66 >
67 >
68 > we put a blocker into the depends, so, that users have to unmerge there
69 > already installed apache before doing an upgrade. My proposal *now* would
70 > even be, to block actual apache{1,2} installations in pkg_config() that still
71 > have old configuration files in /etc/apache{,2} around.
72 > So, the user is enforced to have a look at it when having done the upgrade.
73 >
74 > src_config() {
75 > if test -e ${APACHE_CONFDIR}; then
76 > einfo "${Place_here_the_info_text_and_URL}"
77 >
78 > die "Old configuratioin files detected. Please remove them \
79 > before upgrading to new apache."
80 > fi
81 > }
83 That will help some but may cause other problems.
85 > However, I know, that not all ppl would like such a behavior anyway. But doing
86 > everything automatically isn't just the best option. For this, the old
87 > configuration has been just *too* crappy to realize auto adaption of of the
88 > old configuration data into the new layout.
90 Please make this change backwards compatible before putting in ~, thats all I
91 ask. Its crazy to do this kind of a change without making any part of it
92 backwards compatible for at least a certain amount of time.
94 --
95 Lance Albertson <ramereth@g.o>
96 Gentoo Infrastructure | Operational Manager
98 ---
99 Public GPG key: <>
100 Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742
102 ramereth/


File name MIME type
signature.asc application/pgp-signature