1 |
Hi Mark, |
2 |
|
3 |
I'm in full agreement with you that work is needed on ports stability. |
4 |
I think, however, that I have a slightly different perspective. First, |
5 |
I think that it is amazing and groundbreaking that gentoo can have two |
6 |
different architectures running, if not perfectly, then at least very |
7 |
well indeed from a single package tree. As you know, the ppc port is |
8 |
still really in its infancy, and it's a testament to the power of |
9 |
Portage that it works as well as it does already. I think we need to |
10 |
decide what our priority is: is it to have a stable ppc distro asap, or |
11 |
is it to do something new and exciting, and still get a stable distro |
12 |
after just a little while longer - one that will be a model for linux |
13 |
distributions for some time to come? To put it another way, to opt for |
14 |
separate trees would be to sacrifice exactly what is so special about |
15 |
gentoo-ppc: it's not a separate distro from gentoo-x86, it just _is_ |
16 |
Gentoo, and for me that's about as cool as it gets. |
17 |
|
18 |
Another point: I've been using gentoo-x86 for quite a while now, and it |
19 |
has its own share of QA problems (and this is its acknowledged #1 |
20 |
priority now). For now, it's just the gentoo way to have a few things |
21 |
broken. I'm not saying it should stay that way, but if gentoo-ppc |
22 |
"looks bad" because of broken stuff, that's not unique to gentoo-ppc :-) |
23 |
|
24 |
Well, none of this invalidates your complaints - I just want to draw |
25 |
attention to the importance of priorities. As for actual fixes, I'm all |
26 |
for the improved masking schemes. I suggest, too, that we (ppc-devs) |
27 |
make it our business to stay up to date on exactly what gets changed in |
28 |
portage from this point of view, and to disseminate clear info to all |
29 |
other gentoo devs so they know what needs to be done. Some important |
30 |
recent changes (slots, licenses...) have appeared without much |
31 |
documentation about usage, and that makes devs wary of using them. We |
32 |
don't want this to be the case with changes that affect the ports. |
33 |
|
34 |
Another idea (you and I discussed this one on irc the other day): since |
35 |
repoman and lintool are being made pretty much necessary for committing |
36 |
ebuilds, how about adding functionality to them to flag arch-dependent |
37 |
issues (e.g. if a patch is added to source, have lintool ask "is your |
38 |
patch arch-independent?"). |
39 |
|
40 |
David |