1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On 18-07-2010 00:58, Brian Harring wrote: |
5 |
> On Sun, Jul 18, 2010 at 02:56:05AM +0300, Alexis Ballier wrote: |
6 |
>> case ${EAPI:-0} in |
7 |
>> 2|3|4) ;; |
8 |
>> *) DEPEND="EAPI-TOO-OLD" ;; |
9 |
>> esac |
10 |
>> |
11 |
>> why not: |
12 |
>> |
13 |
>> case ${EAPI:-0} in |
14 |
>> 0|1) DEPEND="EAPI-TOO-OLD" ;; |
15 |
>> esac |
16 |
|
17 |
Alexis, |
18 |
|
19 |
the problem with your alternative is that it's "too clever" and won't |
20 |
die/kill/stop the processing of the eclass for newer EAPIs that at any |
21 |
point in time no one can be sure will be compatible with the current |
22 |
eclass design. |
23 |
That's why it has been agreed that eclasses should specifically list all |
24 |
supported EAPI versions and die/kill/stop on all other EAPI versions. |
25 |
|
26 |
> Do not go adding invalid DEPEND like that. Make the eclass die |
27 |
> instead. |
28 |
|
29 |
Brian, |
30 |
|
31 |
this is being used in the tree already. |
32 |
IIRC, since the introduction of EAPI-2 in the tree, there were a few |
33 |
solutions present to the dev ml and the one agreed by people was the |
34 |
abuse of depend to have the PM fail on dependency resolution instead of |
35 |
calling die on an eclass - which iirc is / was forbidden by PMS. |
36 |
We can discuss the correctness of this use, but please take into account |
37 |
it's already being used so until we have such a discussion we can't |
38 |
"forbid" its use. |
39 |
|
40 |
grep EAPI-TOO-OLD $(portageq portdir)/eclass/* |
41 |
/home/gentoo-cvs/gentoo-x86/eclass/kde4-functions.eclass: *) |
42 |
DEPEND="EAPI-TOO-OLD" ;; |
43 |
/home/gentoo-cvs/gentoo-x86/eclass/poppler.eclass:has 2 ${EAPI} || |
44 |
DEPEND="EAPI-TOO-OLD" |
45 |
/home/gentoo-cvs/gentoo-x86/eclass/virtuoso.eclass: *) |
46 |
DEPEND='EAPI-TOO-OLD' ;; |
47 |
|
48 |
> Seriously, and this is a general rant based on several years of |
49 |
> people adding stupid shit without considering the fallout: |
50 |
> |
51 |
> Whatever great new little trick you can think of for stuff like |
52 |
> this... it's wrong. Use the mechanisms that exist. If policy |
53 |
> forbids it, fix the policy, don't come up w/ "clever" hacks around |
54 |
> it. Fix the core issue instead. |
55 |
> |
56 |
> Wouldn't surprise me if portage would accept this and run with it, |
57 |
> blowing up at emerge time instead. Pkgcore and paludis however will |
58 |
> give you the finger *very* quickly since that's not a valid atom. |
59 |
> Don't piss on our parties w/ 'clever' tricks, do the right thing and |
60 |
> use a die. |
61 |
> |
62 |
> People will move their ass a helluva lot quicker when their ebuild |
63 |
> breaks than when bones has to go yelling both at the eclass author, |
64 |
> and the devs in question about missing deps. |
65 |
> |
66 |
> Do not add this to the tree. |
67 |
|
68 |
See above that this is already in the tree and has been for a few months |
69 |
(years?) |
70 |
|
71 |
> ~harring |
72 |
|
73 |
- -- |
74 |
Regards, |
75 |
|
76 |
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org |
77 |
Gentoo- forums / Userrel / Devrel / KDE / Elections |
78 |
-----BEGIN PGP SIGNATURE----- |
79 |
Version: GnuPG v2.0.15 (GNU/Linux) |
80 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
81 |
|
82 |
iQIcBAEBAgAGBQJMQl7jAAoJEC8ZTXQF1qEPQuIQANWeUwpZFNfsY6wkDWCOI+xR |
83 |
p4sYPRiHStY4nCJ6IZ/DGvBNnrvo+KDn3P5vT9uHT4x50cE5bYeyz4l+DCjXYtCp |
84 |
ey7rGL3P7l9vNtf6Vg7+8imaGbgGnr2mZQ8Pmn1ZWXaYW8i2e5yyTeUpvqH3TH2v |
85 |
ASKYIg5VlS3MeiP2unOQfuLXqRDcyXxMPnG6xj3pl2PpGMT3X+rAAkLDqGKRcZJj |
86 |
7uA0oVUdjWM5HTKqZKYRbYpLo5veawVC+FMR4Z4DA6yhgtYsUQ+mTYnfjGgavCah |
87 |
KU881TUaZQajDSXVK4m1V8q8Zg0ge0vjeXN15CPhPFfnSyCqf6GbkPZE7OjizJdu |
88 |
vA8uoYjEMNXTAnE+TS1h18I+Cs3rL8CA+sxbHZgING5cfg8DtfRRW02zJzicaLxP |
89 |
tIlotZpefEKWrTBKPrfGjhk0Te/IjvUAyLfx77Q5qqKxihBxy9T0DSe7TA0Azwkk |
90 |
B9eW9Cn1UeoHeV1M+/kD4oXna+d66rOHLXP7LerQjm7ZqII5MwGRA7yC7RhGDyvO |
91 |
oCsOCii9iuBR5n+qc8dvlN9oYyrVuDE22a4LsBGSXIse9Z8C1fBayUwYTkbAJLA0 |
92 |
uKqYvElfvJoH9hjJud01iQtQ7GxTEdlT0HaeV085Tvq6D/eoK1U+tGlTeFZXNkFb |
93 |
+6R9ncUuA0AeKcfVvJ2P |
94 |
=8vjx |
95 |
-----END PGP SIGNATURE----- |