1 |
On Tue, May 16, 2006 at 03:56:38PM -0700, Brian Harring wrote: |
2 |
> If your parent parsing implementation handled N parents on a single |
3 |
> line (rather then parent per line as you do now), portage would |
4 |
> explode rather then silently use the left most. Your implementation |
5 |
> isn't doing that however... |
6 |
|
7 |
And that won't even work. Woot. About the only guranteed "portage |
8 |
will choke and not invalidly use N parent profiles if it doesn't |
9 |
support it are"- |
10 |
1) specify the parents prefixed with #, fex |
11 |
# .. |
12 |
# ../blah |
13 |
End result is that python will throw a TypeError (might be |
14 |
ValueError). Not incredibly clean. |
15 |
2) insane profile inheritance version trick. Require the |
16 |
leftmost parent to point at a custom profile, say profiles/version1, |
17 |
which has a nice little bashrc along the lines of |
18 |
die "upgade your $PKG_MANAGER- your current version cannot parse this |
19 |
profile properly". |
20 |
If the package manager knows of version1, it just filters that parent |
21 |
out as it goes- if it doesn't, any/all ebuild actions result in a |
22 |
forced bail as soon as control is transfered over to ebuild env. |
23 |
|
24 |
Both solutions suck, and the alternatives of "just ignore it" or |
25 |
"require left parsed profile to be minimally sane" don't cut it all |
26 |
that well. |
27 |
|
28 |
~harring |