1 |
On Wed, Jun 12, 2013 at 10:23 AM, Michael Orlitzky <michael@××××××××.com> wrote: |
2 |
> On 06/12/2013 01:13 PM, Ciaran McCreesh wrote: |
3 |
>> On Wed, 12 Jun 2013 19:05:29 +0200 hasufell <hasufell@g.o> |
4 |
>> wrote: |
5 |
>>>> Isn't it more an indication that Gentoo needs better package |
6 |
>>>> management support for overlays? |
7 |
>> |
8 |
>>> No. |
9 |
>> |
10 |
> |
11 |
> We need worse support for overlays, i.e. no. Having to use >3 overlays |
12 |
> defeats the purpose of a QA'd tree. |
13 |
|
14 |
Disclaimer: I'm not a Gentoo developer -- actually, fuck that noise, I |
15 |
am a Gentoo developer. But you know what I mean. My knowledge of the |
16 |
gentoo QA process is limited to what I've been able to glean as a |
17 |
beneficiary of the work and a limited participant via the bugzilla |
18 |
system. The precise mechanisms and policies that drive Gentoo QA are |
19 |
actually fairly opaque to me. |
20 |
|
21 |
Anyhow... wrt overlays "defeating the purpose" of QA: overlays may or |
22 |
may not prevent the QA process from pertaining to users of overlays, |
23 |
depending on the nature of the overlays. But, in fact, far from |
24 |
defeating the purpose and integrity of Gentoo QA, my belief is that by |
25 |
providing a standard baseline that QA may rely upon, overlays serve to |
26 |
enhance and protect Gentoo's quality. |
27 |
|
28 |
consider: emerge --info provides the overlays in bug reports to gx86 |
29 |
package maintainers and, if there is doubt about the sanity of the |
30 |
overlays, maintainers are (I presume) free not to support nonstandard |
31 |
configurations. But if a bug-reporter has this problem, the overlay |
32 |
system actually protects them. If they feel they are left |
33 |
high-and-dry due to their nonstandard gentoo installation, and are |
34 |
sure that their bug is a legitimate gx86 bug, they are free to whip up |
35 |
a virtual machine or to temporarily drop their overlays and CFLAG rice |
36 |
and emerge --depclean && emerge -e system. |
37 |
|
38 |
Assuming they turn out to be right, bug reporters and package |
39 |
maintainers can be sure to be roughly on the same page wrt |
40 |
reproducibility. Indeed, no matter what kind of personality conflicts |
41 |
or other nontechnical issues may be at play, the reporter of a |
42 |
legitimate bug is pretty much guaranteed to get some kind of |
43 |
resolution to his issue, or at least that has been my experience. If |
44 |
bug reporters don't like those results and want to implement a |
45 |
different solution than the one they got, overlays enable them to do |
46 |
that as well. |
47 |
|
48 |
In short, overlays permit Gentoo to maintain reasonable quality |
49 |
standards while encouraging innovation and casual experimentation. |
50 |
Larry the Cow approves of them. |
51 |
|
52 |
> Everything in an (official) |
53 |
> overlay should be in package.mask instead. The main reason it isn't is |
54 |
> because nobody wants to use CVS. For good examples, see sunrise or |
55 |
> gentoo-haskell. |
56 |
|
57 |
Such a policy might be OK for developers who are able to just hop on |
58 |
and make changes to gx86 without going though the whole bugzilla |
59 |
process, hence "official". |
60 |
|
61 |
However, it seems like you're thinking of overlays as piles of package |
62 |
ebuilds which haven't yet made it into stable. They may be that, or |
63 |
they may not -- overlays can add profiles, modify core eclasses, or |
64 |
even replace portage itself with a customized variant, and who knows |
65 |
what else. As another poster pointed out sarcastically, the GSOC |
66 |
types of projects clearly don't comport well with this, even if |
67 |
certain things like, i.e., sunrise, arguably might. |
68 |
|
69 |
Anyhow, isn't the gentoo-x86 tree already plenty big enough, without |
70 |
every single overlay's ebuilds and eclasses in there too? Personally, |
71 |
I'm inclined to wish it was smaller, even if that meant more stuff was |
72 |
pushed into overlays, although I suppose that might have a negative |
73 |
impact on QA coverage without some corresponding changes on the QA end |
74 |
of things... I guess I don't know enough about it to speak |
75 |
confidently. |
76 |
|
77 |
As a huge consumer of the overlay and layman mechanisms, both as a |
78 |
user and a developer, there is absolutely no doubt in my mind that by |
79 |
far the gravest problem with the overlay architecture is its inability |
80 |
to create direct VCS connectivity between an overlay and its upstream |
81 |
PORTDIR (coupled with it's requirement to clone entire package |
82 |
directories instead of overriding them on a per-file basis). FWIW, I |
83 |
have nascent ideas about how to fix that, but they are quite radical, |
84 |
probably half-baked (even just as vaporware ideas), and arguably |
85 |
off-topic, so I won't elaborate. |
86 |
|
87 |
-gmt |