| 1 |
28.2.2006, 20:59:42, Mike Frysinger wrote: |
| 2 |
|
| 3 |
> On Tuesday 28 February 2006 12:51, Renat Lumpau wrote: |
| 4 |
>> On Tue, Feb 28, 2006 at 05:11:57PM +0000, Ciaran McCreesh wrote: |
| 5 |
>> > And it sticks out a nasty ewarn and says that the ebuild is probably |
| 6 |
>> > broken. |
| 7 |
>> |
| 8 |
>> Which it _probably_ is. See, this is a numbers game. In most cases, if you |
| 9 |
>> use the webapp eclass, setting SLOT="0" is incorrect. There are some cases |
| 10 |
>> in which it's just fine. Until FEATURES="mindreader" is implemented, how is |
| 11 |
>> the eclass to know what you're trying to do? So it prints a warning and |
| 12 |
>> doesn't die. Number of angry users storming bugs.g.o - 0. |
| 13 |
|
| 14 |
> why do you need to be a mindreader ? the user requested they control the |
| 15 |
> package, thus it isnt a bug, so dont issue a warning |
| 16 |
> -mike |
| 17 |
|
| 18 |
Sure, and when *ebuild* requested it instead, then portage will be |
| 19 |
automagically informed. So yeah, we can implement yet another variable into |
| 20 |
the eclass, and we can do tons of other magic voodoo about three lines of |
| 21 |
eclass that noone has ever noticed until today, and the whole thing can be a |
| 22 |
lot more complex for sure. Sorry, I call this a complete waste of time. |
| 23 |
|
| 24 |
-- |
| 25 |
|
| 26 |
jakub |
Archives