1 |
On 03/13/2012 07:38 PM, Brian Harring wrote: |
2 |
> On Tue, Mar 13, 2012 at 07:05:57PM -0700, Zac Medico wrote: |
3 |
>> If all package managers adhere strictly |
4 |
>> to these two requirements, then we won't have any incompatibilities |
5 |
>> between package managers here. |
6 |
> |
7 |
> You're missing a lot of the point here; defining some search algo is |
8 |
> basically screwed at its core due to the flexibility of bash. Simple |
9 |
> example: |
10 |
> |
11 |
> if [ "$PV" -eq 9999 ]; then |
12 |
> EAPI=3 |
13 |
> else |
14 |
> EAPI=2 |
15 |
> fi |
16 |
> |
17 |
> The flexibility of bash means that your attempt to enforce simplistic |
18 |
> rules like "it must be greppable" are at loggerheads; if the rules |
19 |
> were "last is the one thats used", then I just invert the if check. |
20 |
> |
21 |
> Yep, the above is stupid code. Frankly, the sort of stupid code |
22 |
> I'd expect out of a newbie ebuild dev. The EAPI bit there is |
23 |
> synthetic, but that sort of construct (putting everything into a |
24 |
> single file, then using symlinks to expose differing versions) is out |
25 |
> in the wild and used. |
26 |
> |
27 |
> The fact that potential exists is a flat out sign the approach is |
28 |
> broken. Worse, it's a way to trip up people- specifically new devs |
29 |
> who don't know fun rules like "the PM has this lovely search algo for |
30 |
> getting EAPI that you must abide by". |
31 |
|
32 |
It won't be a problem because the package manager can reject the ebuild |
33 |
as soon as the dev tries to execute it the first time, and it will refer |
34 |
the dev to the section of PMS that specifies the search algorithm. |
35 |
|
36 |
As for ebuilds in the wild that already do stuff like that, it's not a |
37 |
problem if we only require the search algorithm to work starting with |
38 |
EAPI 5. |
39 |
-- |
40 |
Thanks, |
41 |
Zac |