A few months ago I’ve written about DEPEND and RDEPEND; as Josh noticed in the comments, I’ve outright ignored PDEPEND in that instance, since I didn’t really want to open a can of worms relating to that. Now I think it would be a nice time to open that can of worms.
Portage already started blurring the separation between RDEPEND and PDEPEND; PDEPEND may be brought in before the package it’s reported in, to help breaking dependencies; which is, after all, what PDEPEND was born for, as both Petteri (in that post) and I think Brian (some time ago) repeated. I think this would be a nice starting point for trying to blurr and finally remove the separation between RDEPEND and PDEPEND.
I got htis idea while doing my tree-build for testing, the idea is that -B should work; but it really doesn’t a lot of times, since developers try to see if their software builds in general; rarely they test if it builds on a clean slate chroot; even more rarely they check it builds without its RDEPEND installed. I’ve been fixing a few of these problems in the tree, without even asking to be honest, as this usually comes down to bitrot that predates EAPI ideas (empty DEPEND meant “use RDEPEND” in the past), or to typos (REDEPEND or DEPEND=$DEPEND), so they are very trivial to fix. But this is far from optimal since I’m testing one package after the other and it’s not really so easy.
An option I proposed to Zac was to make portage have a developers-only option that installed packages treating RDEPEND as PDEPEND, so that the build of the package is triggered without having the runtime dependency installed. This was what made me think about it.
If every package was stating DEPEND and RDEPEND properly, PDEPEND wouldn’t be needed at all; the package manager would be allowed to treat packages in RDEPEND only so that installing them would be indifferent before or after the package that brought them in. Now of course this has a bit of a problem: if a dependency failed to install and was installed after the package you’d be having a non-working installed package, so I guess it’ll have to be evaluated quite more deeply, but it at least seems an idea to think about.
Of course making this change will require a new EAPI, so the proposal should be prepared as soon as possible so that it will fill in the tracks for EAPI=3, but that’s beside the point right now, I just wanted to put in writing an option that I think would be very nice indeed to simplify ebuild writing (dropping a whole class of dependencies!) and at the same time allow for proper dependency cycles breaking.
Now of course, before this can be even considered, it’d be nice if the tree was checked properly for dependencies…