FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Portage Developer

 
 
LinkBack Thread Tools
 
Old 04-23-2010, 12:43 PM
Sebastian Luther
 
Default DEPEND with unevaluated use conditionals in vdb

Hi everyone!

Some weeks ago [1] portage changed its behavior regarding what gets
stored as *DEPEND in the vdb. The curret behavior is to store the
*DEPEND variables with evaluated use conditionals. That is, if the
package has DEPEND="foo? ( cat/pkg2 )", either DEPEND="cat/pkg2" or
DEPEND="" end up in the vdb, depending on the state of the use flag 'foo'.
The old behavior was to store the unevaluated string. In the example
above DEPEND="foo? ( cat/pkg2 )" would have been stored in the vdb.

I propose to revert back to the original behavior.

What is the proposed change good for?

I see two reason. The first one more ideological and reads: "Don't throw
away information for no good reason". I say for no good reason, because
the evaluated value is easy to compute for users of the portage api,
where the unevaluated value is lost.

The second reason is that I want it to detect cases where the *DEPEND
variables have been changed without rev bump. To do this I want to
compare the *DEPEND string of the ebuild and the installed package.

Why can't you use the evaluated *DEPEND string?

Form time to time ebuilds get use flags added to IUSE without rev bump.
If the new use flags are used in *DEPEND variables and I evaluate the
use conditionals based on the enabled use flags of the installed
package, I'll always treat the newly added use flag as disabled. The
problem is that this might be wrong.
Consider this example:
installed package:
IUSE=""
RDEPEND=""
ebuild:
IUSE="some_feature"
RDEPEND="some_feature? ( cat/pkg2 )"
Assume the RDEPEND of the installed package is wrong, that is it should
have had cat/pkg2 in RDEPEND. After the maintainer noticed that, he
added a flag to disable the feature that needs cat/pkg2. Since
some_feature will be treated as disabled when the use conditionals in
the ebuild's RDEPEND are evaluated, RDEPEND will look unchanged. That
means portage won't pick up the change when it should.

Someone might come up with some logic to detect new use flags in
*DEPEND, but this looks like a hack to me. The clean solution is to
store the unevaluated string.

Question is: Does anyone have a good argument to not use the old
behavior again?

Sebastian

[1] commit e6be6590e99522f9be69e2af8eff87919d9bf31f on 2010-02-14
 
Old 04-24-2010, 05:31 AM
Zac Medico
 
Default DEPEND with unevaluated use conditionals in vdb

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.

> 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.

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).

> Question is: Does anyone have a good argument to not use the old
> behavior again?
>
> 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.
--
Thanks,
Zac
 
Old 04-24-2010, 11:32 AM
Gentoo
 
Default DEPEND with unevaluated use conditionals in vdb

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.
>
> > 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.
>
> 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).
>
> > Question is: Does anyone have a good argument to not use the old
> > behavior again?

space and ease of parsing for minimal pkg mergers.


> >
> > 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.
 
Old 04-24-2010, 06:00 PM
Sebastian Luther
 
Default DEPEND with unevaluated use conditionals in vdb

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.

>>
>>> 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?

>>>
>>> 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?
 
Old 04-24-2010, 06:27 PM
Zac Medico
 
Default DEPEND with unevaluated use conditionals in vdb

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
 
Old 04-24-2010, 07:28 PM
Brian Harring
 
Default DEPEND with unevaluated use conditionals in vdb

On Sat, Apr 24, 2010 at 11:27:49AM -0700, Zac Medico wrote:
> 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).

Offhand, the tree should be clean on this account- pcheck has scanned
for it since near day one. You also need to scan LICENSE, SRC_URI,
and RESTRICT btw.

~brian
 
Old 04-24-2010, 08:38 PM
Gentoo
 
Default DEPEND with unevaluated use conditionals in vdb

On Sat, 2010-04-24 at 20:00 +0200, 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.
>
> >>
> >>> 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.

We actually had flattened R/DEP's before for a while. Then they got
removed then noew added back.

> For portage API users, the difference is
> a (rather long) one liner.


> What do you mean with space?

The vdb is getting rather bloated. Anything that cuts down excess waste
there for the masses I tend to be in favor of.

> >>>
> >>> 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 just add bloat back. I think the real problem here in the example
you listed in the first email, is that ebuild authors should be bumping
a package when adding/removing functionaliy provided by IUSE. Infact
it's even a policy & part of our own ebuild quizzes that they should
bump the pkg (eclasses excluded).

--
Gentoo <solar@gentoo.org>
Gentoo Linux
 

Thread Tools




All times are GMT. The time now is 01:02 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org