Re: [gentoo-portage-dev] [RFC] Store [,R,P]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?
Re: [gentoo-portage-dev] [RFC] Store [,R,P]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
Re: [gentoo-portage-dev] [RFC] Store [,R,P]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 pgpbdWHuynx1g.pgp Description: PGP signature
Re: [gentoo-portage-dev] [RFC] Store [,R,P]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 so...@gentoo.org Gentoo Linux
[gentoo-portage-dev] [RFC] Store [,R,P]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
