In the installer, I use 'emerge -p whatever' to get a list of packages that need to be quickpkg'd from the LiveCD and emerge -K'd into the chroot for a GRP install. This list ends up containing stuff like nasm, which isn't needed for a GRP install and isn't present on the LiveCD (built from catalyst pkgcache). Because of this, I can't know if a package failing to quickpkg is a problem or not. The 'emerge' command should have a commandline option that tells it to only pay attention to RDEPEND (or atleast ignore DEPEND) when calculating the deptree. I don't know the portage code well enough to make a patch, but zmedico says it looks pretty easy to do since the functionality is already there for emerging a binary. Me love you long time if this feature appears in portage stable in time for 2006.0 :)
Created attachment 72263 [details, diff] patch to emerge that adds a --nodepend option I tested this patch by comparing "emerge -pe world" to "emerge -pe --nodepend world" and it seems to work.
Since this code is already "tried and true" for binpkgs, is there any reason this can't be put into the next release? It could be an "undocumented" feature, since we really don't need to give users yet another way to shoot themselves in the foot :)
Created attachment 74541 [details, diff] portage-2.0.53-accept_depends.patch Trying to kill two birds with one stone here. vs calculating depends with what you dont want how about calculating them with only what you do want. See attached patch for details.
After talking to ferringb a bit, it's apparent that this feature needs a bit more justification. Here is the situation in which something like this would be needed: The installer currently supports GRP by quickpkg'ing packages from the running LiveCD with PKGDIR set to /mnt/gentoo/usr/portage/packages and then 'emerge -K package' inside the chroot. This works just fine. The problem is in determining which packages need to be pulled from the LiveCD. I'm running 'emerge -p package' inside the chroot and parsing the output with a few passes through sed to determine which packages I need to quickpkg. This also works just fine. Here is where the problem comes in. That list of packages I now have is everything that is needed to *compile* the particular package. However, I'll be doing a binary install, so packages like nasm aren't required and won't exist on the LiveCD if it was built using portage's pkgcache. At this point, I know that I couldn't quickpkg nasm, but how do I know if that's something that can be ignored or an actual problem? This patch would allow me to easily generate a list of packages needed for a *binary* install of a certain package without needing to have the binpkgs present beforehand. As far as I can tell, it has absolutely no negative side effects if you don't use it. It was also mentioned to me that indirection would be needed for this to work. The worry is that someone could pick up an installer LiveCD from a year ago, and there is now a new version of portage out that no longer has this hack but instead has a proper library for doing this type of thing. IMO, there is no need for this approach. This would *only* be used for a GRP install. For a GRP install, you would have to use a portage snapshot from the same time as the LiveCD release. This older snapshot would have the older portage that still has the hack in place. For any given release, the portage snapshot is mostly frozen atleast a few weeks beforehand. We would know when the new portage version is approaching stable and then still have a few weeks after knowing for sure if it ends up in the snapshot. This would be plenty of time to switch the installer's package dep grabbing code from calling emerge to using the backend libs. If there are any other reasons for not including this patch into portage, please let me know. A major overhaul of the installer's GRP code is waiting on support for this in portage. I'm hoping for this to make it into stable portage by 2006.0.
Won't put this directly into emerge.
