If dependencies are unsatisfied, it can lead to be impressed that there is a bug with the package; whereas actually the dependencies just weren't emerged. `ebuild ...` should bail out early if dependencies are missing, to avoid problems... See bug #499742 comment #1 for an example of how I am fooled by this.
I hope that doesn't include "ebuild ... manifest" or else I see my workflow becoming uselessly complicated. To be honest I see the "ebuild" command as a low level tool for handling ebuilds, so making it check dependencies is out of that program's scope IMHO. "emerge" already does that perfectly fine and if you want to make sure a package's dependencies are satisfied, use "emerge -1ov $pkg". In the end if this gets implemented I hope it will be optional so people who prefer current behavior of "ebuild" still can use it that way.
I agree with Poly-C. The ebuild command was never meant to be a package manager but just a low level ebuild handler. Running ebuild manually to install is only meant for debugging purposes so that a dev can run thru the stages manually. They can then work in the code, find out what is going wrong, create patches,... Running ebuild manually has always been "User BEWARE".
But can we improve the development workflow here? (`emerge ...` is tedious) Is there an actual reason to not ensure proper dependencies?
Hi Tom, Can you describe the workflow, including its deficiencies? Improving the workflow is perhaps orthogonal to adding dependency resolution to the 'ebuild' tool; perhaps we can focus this bug around what we want to improve, and less on how exactly we might accomplish it. -A
`emerge -1 FULLATOMANDVERSION` is more tedious to type than `ebuild TABCOMPLETE`; on top of that, you need to unmask and/or accept keywords in the former case. Whereas the latter just proceeds. Hence, it would be nice that the latter would do dependency checking (not dependency resolution, which is different and rather costly) such that one cannot run `ebuild TABCOMPLETE` without the dependencies being present. Why list dependencies in an ebuild and not check them? Is there a reason against implementing? I haven't heard any such reason yet...
`ebuild` is a direct tool. it should not be doing dependency checks as the normal course of things. it's way too slow for it and most of the time, it's not even wanted/needed. it's like saying "why does `rm /lib/libc.so.6` let me delete the library even though /bin/bash needs it". in the past, we had support for `emerge <ebuild>`. i used to use it a lot. has that rotted since ? if not, use that. if it has, let's fix that.
(In reply to SpanKY from comment #6) > `ebuild` is a direct tool. it should not be doing dependency checks as the > normal course of things. it's way too slow for it and most of the time, > it's not even wanted/needed. it's like saying "why does `rm /lib/libc.so.6` > let me delete the library even though /bin/bash needs it". We came down to this in #gentoo-portage, I agree; I just want to have a workflow that works properly again. But a workflow that doesn't induce too much waiting time if possible, as that's why I moved to ebuild as my main ebuild testing tool. I will look into switching to emerge, given that we can make it work again. > in the past, we had support for `emerge <ebuild>`. i used to use it a lot. > has that rotted since ? if not, use that. if it has, let's fix that. +1 It gives odd errors but seems to work in the Portage tree, but doesn't seem to work outside of that, it also breaks when you pass a path I think; it thus handles less than ebuild handles. Regardless of that, to spare out time that the command takes, I would appreciate a way to only check the immediate dependencies instead of resolving the dependency tree; is this already possible using current parameters? Given it has broken, and thus is a regression; this is more than an enhancement.
