Ciaran McCreesh <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 19 Apr 2008 06:33:00 +0100:
> On Fri, 18 Apr 2008 22:27:21 -0700 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: >> My interpretation is pkg_* counts as runtime (I can imagine a package >> wanting to run itself at this point), so packages in RDEPEND should be >> usable at that point. > > Which would be fine, except it makes the tree unusable. > >> Really, it seems to be an additional type of dependency that neither >> DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND idea isn't >> quite capturing it either. > > Yup, and for future EAPIs labels can fix this. But we have to have a > sound solution for current EAPIs. It seems to me that at least for current EAPIs, RDEPEND simply cannot be depended upon during pkg_*inst without breaking things. I can't see a way around that. About the least-bad of multiple bad solutions I can see for Donnie's conceivable run scenario would be to print a message in pkg_postinst telling the user to run emerge --config before running the program normally, maybe even going to the point of renaming the runtime and installing a fake that reminds folks to run emerge --config first, if it's critical enough. (pkg_config would then kill the fake and rename the runtime back to its proper name.) Now consider binary packages. DEPEND can't be used as-is, which in the OR case would then mandate RDEPEND and again result in broken behavior due to circular dependencies, so that simply doesn't work. That leaves the intersection of both DEPEND and RDEPEND sets as the only possible logically consistent resolution... UNLESS we either (1) accept that binary package behavior simply can't be correctly defined under current EAPIs and declare it an indeterminate legacy exception, or (2) declare binary packages an exception that works by different rules, and then define them (somehow). Either alternative would then leave somewhat more flexibility for the ordinary build case, presumably enough to reasonably accurately describe current behavior deterministically. (I'll freely admit to not knowing enough about current tree behavior to pick the right option there.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
