On Sat, 2008-04-19 at 06:33 +0100, Ciaran McCreesh wrote: > 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.
I would agree that RDEPEND should likely be installed prior to pkg_preinst to satisfy the dependency. After all, PDEPEND is "good enough" for doing packages that aren't required at pkg_preinst/pkg_postinst. We definitely don't want to install DEPEND at the pkg_* stages, so I'd say the requirement there, if you're asking, is prior to src_*, if that matters. I'd love to have some kind of functionality to allow some kind of "optional" dependencies. The only real way that I could see this working is if we tracked what was installed as an optional dependency, and not reinstall it if it has been removed the next time the depending package is merged. Simple example: ODEPEND="video_cards_nvidia? ( x11-drivers/nvidia-drivers)" would install x11-drivers/nvidia-drivers the first time it's ran with VIDEO_CARDS="nvidia", but if I removed x11-drivers/nvidia-drivers, it wouldn't get reinstalled. This would probably need some kind of "--newuse" like capability to allow for installing only *new* optional dependencies, but I think that the tracking would already allow that. The idea here would be to allow for installing "recommended" software along with others. We could even have --ask ask for the dependencies, since they are optional, after all. This way, we could "ship" a more robust configuration/setup for many popular applications without forcing software on people. It's an idea, anyway, and I hope that I didn't hijack the thread. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer
signature.asc
Description: This is a digitally signed message part
