I’m still working on getting ebuild dependencies into the database so I can query them with GPNL. Getting the actual deps was easy, and that part I just barely wrapped up tonight. The hard part is getting a fine-grained look at which dependencies are which.
Right now, I’m not too sure what the SQLite database generated by portage is doing, as far as setting DEPEND and RDEPEND. It *looks* like it’s dumping all of RDEPEND into DEPEND, which makes sense as far as pulling in which packages to install, but that makes it hard on me to determine what the actual run time deps are — assuming that’s what it’s doing. The fact is, there’s a number of possibilities (no DEPEND, no RDEPEND, empty DEPEND, empty RDEPEND, packages in both, etc.) that really the best way to determine which is which is to do something I should have done a long time ago, which was to write something that will parse the ebuild files directly for the variables. Then I could easily see which ones are set, and which ones are included.
The fact is, though, that I wouldn’t have been able to do that until recently anyway, and the first time I tried it was when I first started on the package. At that time, it was a such a disastrous mess trying to parse them as text files because you have random comments and straying lines and unquoted variables that it was just too much of a hassle to deal with. Now that I’ve got regular expressions setup to figure out the difficult stuff like breaking down atoms into every version component and finding the package name from any atom, it should be much simpler to handle.
Until then, though, at least I’ve got dependencies, so I can add support to GPNL real soon now so we can dynamically query which packages at least depend on others.
In setting up the system, I’ve run into some interesting scenarios as well, as is usually the case. I’m always thrown a few curve balls that I never would have expected and they either turn out to be QA issues or gentoo culture that I never could have accounted for. One of them I hit this time was that I kept having ebuilds with dependencies for packages that were no longer in the tree. At first I was confused, as it seemed like an obvious QA bug, but then looking at it closer, (almost) all of them are blockers — that is, don’t include this package in RDEPEND or DEPEND. It leads to an interesting question like, how long should that be in there once the package is removed from the tree? Who knows. It’s fine to leave them in, I guess, but still, it’s interesting to run into stuff like that.
There’s still a lot more work to do, besides breaking down the actual RDEPEND and DEPEND variables more closely. One thing I didn’t realize until tonight is that included in the variable is all the dependencies of the eclasses. So if you have an ebuild using the kde eclass, then the ebuild will also have a dep for system packages like make and libtool. I need to find a way to clean those out as well, obviously.
Fun stuff. I hope to have an additional section soon for GPNL on the ebuild page that will display the dependencies, and in turn a possibility to display them in reverse.