Re: [gentoo-dev] Re: Dependencies that're available at pkg_*inst
On Sun, 27 Apr 2008 10:41:57 +0100 Steve Long <[EMAIL PROTECTED]> wrote: > Use PDEPEND. PDEPEND has a different meaning, and isn't suitable for runtime dependencies. > While I like labels they need to be discussed more on-list as well as > on bugzilla (it's not reasonable for you simply to advertise them and > then close down discussion.) For instance, there is no reason > everything has to be loaded into just one extant metadatum, not do > they preclude new metadata (such as a SRC_DEP here.) Labels can be discussed on-list whenever there's a chance in hell of Portage implementing any non-trivial new features. Anyway, I'm going with the second wording in the original email. It seems fairly clear that most people aren't understanding the issue, and are jumping in and offering opinions without having looked at the tree (and no, I'm not going to give examples, because that'll just degenerate into "oh, so we can change this one particular case to do $blah", whilst missing the bigger point). Of everything suggested, only the two original wordings are correct, and of those two, the second is better defined. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Dependencies that're available at pkg_*inst
Ciaran McCreesh wrote: > On Sat, 19 Apr 2008 18:38:06 +0200 > "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote: >> I don't know what the general use of pkg_preinst is, but in >> pkg_postinst the package itself should be runnable, so its RDEPENDS >> should be installed and usable at this point. So perhaps we should >> define that "usable" means "each of its RDEPENDs is installed and has >> had its pkg_postinst function run". The recursion of that definition >> then comes from the requirement that RDEPENDs should be usable before >> pkg_postinst starts running. > > No good. That prevents RDEPEND <-> RDEPEND cycles from being solved, > and the package manager has to be able to solve that. > Use PDEPEND. >> SRC_UNPACK_DEP="app-arch/unzip" >> SRC_COMPILE_DEP="dev-scheme/bigloo" >> SRC_INSTALL_DEP="" > > Labels are a cleaner solution to this. But again, we're discussing > current EAPIs here. > While I like labels they need to be discussed more on-list as well as on bugzilla (it's not reasonable for you simply to advertise them and then close down discussion.) For instance, there is no reason everything has to be loaded into just one extant metadatum, not do they preclude new metadata (such as a SRC_DEP here.) -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Dependencies that're available at pkg_*inst
Donnie Berkholz <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 20 Apr 2008 22:17:27 -0700: > I guess the RDEPEND+DEPEND case would save an ebuild dev the work of > specifying the COMMON_DEPEND list, but other than that, I can't think of > any benefits. It would force both RDEPEND and DEPEND to be installed for > binpkgs, which sucks. If I read the original proposal correctly, it's not proposing a simple +, that BOTH RDEPEND and DEPEND be guaranteed installed at pkg_*inst, IOW by set theory, not the UNION of the two sets, but the INTERSECTION of the two sets, that is, packages that appear in both lists at once, not those appearing in one XOR the other. Thus a COMMON_DEPEND would still be useful as it would be the list appearing in both (thus effectively the list necessary for pkg_*inst, same as the OR case). Both lists could still exclusively include packages, and packages not listed in DEPEND only would not have to be installed for binpkgs. So it's not OR vs AND, but OR vs INTERSECTION. As I stated in my other post, RDEPEND alone can't be used without breaking things. That applies to binary package installation as well, where DEPEND along can't be used either as that would require installation of unwanted packages. Thus, the OR case doesn't seem to work for binary installation at all, since neither RDEPEND nor DEPEND can be relied upon alone, and the OR case proposes requiring at least one complete set of the two be installed. Thus, for current EAPIs, the INTERSECTION alternative is the only possibly working alternative if we are not to break binary package support and not force full DEPEND installation on binary targets. It's not ideal as it'll potentially force unwanted and otherwise unnecessary package installation on both the build-host and the binary target, due to fact that it forces pkg_*inst dependencies into both DEPEND and RDEPEND, but IMO it's better than forcing the whole set of DEPENDs to be installed on binary targets, which would be the only working alternative in the OR case above. As others have said, this is certainly a good candidate for future EAPI change, but it's not future EAPIs under current discussion, so that fact doesn't help the current discussion. -- 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
Re: [gentoo-dev] Re: Dependencies that're available at pkg_*inst
On Sat, 19 Apr 2008 18:53:27 + (UTC) Duncan <[EMAIL PROTECTED]> wrote: > 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. But DEPEND can't either. The point is, one of the two wordings in the original email is enough. In fact, both are, but they have different implications, and selecting the right one is important. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Dependencies that're available at pkg_*inst
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
