| 1 |
Alexis Ballier kirjoitti: |
| 2 |
> On Tue, 23 Sep 2008 23:33:44 +0300 |
| 3 |
> Petteri Räty <betelgeuse@g.o> wrote: |
| 4 |
> |
| 5 |
>> Bo Ørsted Andresen kirjoitti: |
| 6 |
>>> On Monday 22 September 2008 22:25:20 Petteri Räty wrote: |
| 7 |
>>>>> If you mean something like |
| 8 |
>>>>> |
| 9 |
>>>>> built_with_use cat/foo coolfeature || ewarn "bar will be more |
| 10 |
>>>>> useful if you rebuild cat/foo with USE=coolfeature" |
| 11 |
>>>>> |
| 12 |
>>>>> then you can use |
| 13 |
>>>>> |
| 14 |
>>>>> has_version 'cat/foo[coolfeature]' || ... |
| 15 |
>>>>> |
| 16 |
>>>>> instead. |
| 17 |
>>>> What does this report if cat/foo does not have coolfeature use |
| 18 |
>>>> flag in some version? Meaning can this support cases which need |
| 19 |
>>>> --missing true. |
| 20 |
>>> False. If for instance coolfeature was made optional in >=pv you |
| 21 |
>>> can use logic like: |
| 22 |
>>> |
| 23 |
>>> if has_version '>=cat/foo-pv' && ! has_version |
| 24 |
>>> 'cat/foo[coolfeature]'; then ewarn '...' |
| 25 |
>>> fi |
| 26 |
>>> |
| 27 |
>> I think this should cover all the current functionality with |
| 28 |
>> built_with_use. |
| 29 |
> |
| 30 |
> This is just an ugly hack. Think about a package that has coolfeature |
| 31 |
> useflag removed and enabled by default for a couple of releases because |
| 32 |
> it wouldn't build without it and once upstream sorted out everything |
| 33 |
> the useflag is coming back. Missing useflags that are assumed to be |
| 34 |
> enabled have nothing to do with the package version being greater than |
| 35 |
> a given number. |
| 36 |
> |
| 37 |
> I would *really* prefer having big warnings when using built_with_use |
| 38 |
> in EAPI 2; that way we can see how things are in practice and then |
| 39 |
> maybe make built_with_use die for a later eapi or once all the tree is |
| 40 |
> converted to eapi 2 remove it. |
| 41 |
> |
| 42 |
> Alexis. |
| 43 |
|
| 44 |
Well we could replace the die with eerror but eventually we should get |
| 45 |
rid of vdb access directly by ebuilds. Maybe the next EAPI should add |
| 46 |
something similar to portageq as an abstraction layer. |
| 47 |
|
| 48 |
betelgeuse@pena /usr/portage/eclass $ portageq metadata / installed |
| 49 |
$(portageq match / sys-devel/gcc:4.3) USE |
| 50 |
elibc_glibc gcj kernel_linux libffi openmp userland_GNU x86 |
| 51 |
|
| 52 |
Regards, |
| 53 |
Petteri |
Archives