Gentoo Archives: gentoo-dev

From: Grant Goodyear <g2boojum@g.o>
To: gentoo-dev@××××××××××××.org
Subject: [gentoo-dev] apache and ~arch
Date: Sun, 13 Mar 2005 15:55:28
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.
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 []
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.
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."
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.
48 My thoughts, please feel free to disagree with me.
50 -g2boojum-
51 --
52 Grant Goodyear
53 Gentoo Developer
54 g2boojum@g.o
56 GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76


Subject Author
Re: [gentoo-dev] apache and ~arch kang <kang@g.o>
Re: [gentoo-dev] apache and ~arch Michael Stewart <vericgar@g.o>
Re: [gentoo-dev] apache and ~arch Ciaran McCreesh <ciaranm@g.o>
Re: [gentoo-dev] apache and ~arch Paul de Vrieze <pauldv@g.o>