1 |
Yes, I was one of the many people who emerged the new apache ebuild |
2 |
without paying sufficient attention to the mailing list post announcing |
3 |
the dramatic changes. *Shrug* It took me a day or so to get things |
4 |
fixed, but that was my own fault, and I have no complaints about the |
5 |
new config. |
6 |
|
7 |
On the other hand, I do have a concern about the frequent posts I've |
8 |
seen from our apache devs along the lines of "They [who had broken their |
9 |
systems] obviousely didn't care, [sic] that ~arch is for testing. That of |
10 |
course implies, that not everything will succeed as expected." |
11 |
[http://trapni-akane.org/blog/index.php/trapni/2005/03/12/apache_and_the_enduser] |
12 |
The serious breakage for people occurred because the apache devs |
13 |
released into ~arch the new apache ebuild before a number of rather |
14 |
important apache-module ebuilds had been rewritten to use the new |
15 |
apache config. Now, I think we've all done things like that (forgotten |
16 |
a dependency, or something that uses the current package as a |
17 |
dependency, or missed an obscure USE flag) by accident, and that's why |
18 |
we have an ~arch tree. The ~arch tree, at least in my understanding, |
19 |
is for testing ebuilds, and it's not surprising that sometimes the |
20 |
e-build has an error in it. However, I don't believe that ~arch should |
21 |
be used for ebuilds that one _knows_ have broken functionality. For |
22 |
such cases we have package.mask. |
23 |
|
24 |
So, what should one do about a package that, in and of itself, is fully |
25 |
functional, but related packages have not yet been updated and package |
26 |
maintainers cannot be urged to move faster to fix the packages? Well, nagging |
27 |
on bugs is usually the first step, followed by nagging on -dev so that |
28 |
people know that there is a problem. If that doesn't work, the |
29 |
traditional method is to patch the related ebuilds oneself, add the |
30 |
patched ebuilds to package.mask in a nice big block along w/ the |
31 |
principal package, and start asking people to test. That way, once it |
32 |
appears that the bugs are reasonably worked out the whole block can be |
33 |
unmasked at once, minimizing pain for our users who "can't read". |
34 |
Moreover, once this step is done it is perfectly reasonable to post a |
35 |
bug and a message to -dev saying "New foo system seems to be working, |
36 |
and we plan to unmask all at once in 30 days unless any maintainers of |
37 |
these packages [provide list] explicitly tells us not to do so." |
38 |
|
39 |
Might this approach take a long time and involve a lot of frustration? |
40 |
Yes, of course it might. I understand that in this case the non-masked |
41 |
apache ebuild was lagging further and further behind upstream, and that |
42 |
the frustration for the apache devs was particularly acute. However, I |
43 |
think it's safe to say that our users would rather have older versions |
44 |
with everything working, and the easy ability to use package.unmask if |
45 |
the latest-and-greatest is needed, than to have the latest-and-greatest |
46 |
in a semi-broken state. |
47 |
|
48 |
My thoughts, please feel free to disagree with me. |
49 |
|
50 |
-g2boojum- |
51 |
-- |
52 |
Grant Goodyear |
53 |
Gentoo Developer |
54 |
g2boojum@g.o |
55 |
http://www.gentoo.org/~g2boojum |
56 |
GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 |