Re: [gentoo-portage-dev] [RFC] Store [,R,P]DEPEND with unevaluated use conditionals in vdb

[Zac Medico]

On 04/24/2010 11:00 AM, Sebastian Luther wrote:
> Am 24.04.2010 13:32, schrieb Gentoo:
>> On Fri, 2010-04-23 at 22:31 -0700, Zac Medico wrote:
>>> On 04/23/2010 05:43 AM, Sebastian Luther wrote:
>>>> Someone might come up with some logic to detect new use flags in
>>>> *DEPEND, but this looks like a hack to me.
>>>
>>> It doesn't seem too bad to me.
>
> It doesn't work, because it's not guaranteed, that only use flag from
> IUSE are used in use conditionals. That means you can't do it reliably
> without the unevaluated value.

We can and should add a check to repoman to enforce this. It's long
overdue. The flags already cannot be enabled unless they are in
IUSE, since portage filters them (except for special things like
use.force).

>>>
>>>> The clean solution is to
>>>> store the unevaluated string.
>>>
>>> Do you want to do this for $PKGDIR/Packages as well? We've always
>>> evaluated USE conditionals in there since we were copying the
>>> behavior of the older genpkgindex tool and that's how it behaved.
>>>
>
> We should do it there too for the same reason as for storing it in the
> vdb. Never heard of that tool, but anyone handling portage's binpkgs
> should use the portage api which provides an easy way to evaluate the
> use conditionals.
>
>>> Also note that if we want to rely on having unevaluated strings then
>>> we'll probably want to try to get alternative package managers to
>>> behave the same way (maybe specify it in PMS).
>
> The vdb isn't covered by PMS. Paludis stores the unevaluated value,
> pkgcore stores the evaluated value.
>
>>>
>>>> Question is: Does anyone have a good argument to not use the old
>>>> behavior again?
>>
>> space and ease of parsing for minimal pkg mergers.
>>
>>
>
> Minimal mergers have to handle it anyway, since this has been the old
> behavior until some weeks ago. For portage API users, the difference is
> a (rather long) one liner. What do you mean with space?

He's talking about qmerge from portage-utils. It's a C program
that's intended to merge binary packages on an embedded device that
doesn't necessarily have python installed.

>>>>
>>>> Sebastian
>>>>
>>>> [1] commit e6be6590e99522f9be69e2af8eff87919d9bf31f on 2010-02-14
>>>
>>> I think we'll have to handle the evaluated strings anyway since this
>>> code has already been released and stabilized in portage-2.1.8.x,
>>> and USE conditionals have been evaluate in $PKGDIR/Packages for even
>>> longer. Because of this, I see little or no benefit in changing it
>>> back to unevaluated strings at this point.
>>
>> Good. Thanks for not reverting back to those old behaviors.
>
> And the new use case isn't of any relevance?

> As a compromise: What about storing both values?

That's feasible, but I still think that comparison of evaluated deps
is going to work just fine (and be backward compatible with all
package managers), so storing that additional values seems
redundant. If unevaluated deps are missing (due to alternative
package managers or older portage), it seems like you'll need to
fall back to evaluated comparison anyway.
-- 
Thanks,
Zac