For a description of the problem please read bug #317337. For example sys-kernel/dracut-023 (DEPEND="app-text/asciidoc") currently fails to crosscompile if I do not manually install app-text/asciidoc into the hostsystem, because that is where it tries to run asciidoc from. My proposed workaround until a complete solution for that bug is implemented: Please install DEPEND into both host (i.e. /) *and* target (ROOT=…). In this bug I request the --host-deps flag zmedico suggested. His comment was: --- (In reply to bug #317337 comment #12) > Until this is implemented, could we please install DEPEND into both host > *and* target? That might install a bit more than necessary, but would at > least allow crosscompilation. You can get similar results by using --root-deps and in combination with a hard-host-deps ebuild like they use for chromium-os: http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/portage-build-faq > For example sys-kernel/dracut-023 (DEPEND="app-text/asciidoc") currently > fails to crosscompile if I did not manually install app-text/asciidoc into > the hostsystem, because that is where it tries to run asciidoc from. So, you can create a hard-host-deps ebuild with RDEPEND="app-text/asciidoc". Alternatively, I suppose we could add a --host-deps option that you'd be able to use together with --root-deps to get the behavior that you've requested. --- However, I do not yet fully understand the probosal. Now emerge(1) reads: --root-deps[=rdeps] If no argument is given then build-time dependencies of packages for ROOT are installed to ROOT instead of /. If the rdeps argument is given then discard all build-time dependencies of packages for ROOT. This option is only meaningful when used together with ROOT and it should not be enabled under normal circumstances. For currently supported EAPI values, the build-time dependencies are specified in the DEPEND variable. However, behavior may change for new EAPIs when related extensions are added in the future. How I understand this: no --root-deps: DEPEND goes into /, ROOT gets no packages that are only in DEPEND. RDEPEND goes into ROOT. --root-deps: DEPEND goes into ROOT, / gets no packages that are only in DEPEND. RDEPEND goes into ROOT. --root-deps=rdeps: DEPEND is installed to neither ROOT nor /. RDEPEND goes into ROOT. The consequences of that seem rather complicated to fully understand. It seems like I would need to supply both --root-deps and --host-deps to install DEPEND into both ROOT and /. Question is: What happens to RDEPEND in this case? I propose a simplified set of flags: --install-rdepend={host,root,both} --install-depend={host,root,both} The meaning would be: If =host, install (R)DEPEND into host, i.e. / If =root, install (R)DEPEND into target, i.e. ROOT If =both, install (R)DEPEND into both, host and target, i.e. / and ROOT Defaults would be --install-depend=host and --install-rdepend=root, to mimic current behaviour. You might want to issue a warning (or mention this in the manpage) for combinations that are likely to be wrong, like --install-depend=root and --install-rdepend=host, or remove them entirely. Reproducible: Always
Can someone please set See-Also to https://bugs.gentoo.org/show_bug.cgi?id=317337 ? I am not allowed to make that change.
After discussion in bug #317337 - IMO DEPEND and RDEPEND should affect ROOT by default. Installing RDEPEND into / makes not much sense, since it is only used for building. I'd like to keep things simple and remove --install-rdepend from my suggestion. The defaults would hence be to install DEPEND and RDEPEND only into ROOT. There would be a flag --install-depend with the 3 settings described below (host,root,both, default being root). When HDEPEND gets implemented, this flag should be removed from emerge.
(In reply to comment #2) > After discussion in bug #317337 - IMO DEPEND and RDEPEND should affect ROOT > by default. This is what --root-deps does. Changing the default behavior (without --root-deps option) is not friendly to existing users (like the chromium-os devs), since it can break their build system, so we won't be doing that. It's easy enough to add new options that toggle the desired behavior changes. > The defaults would hence be to install DEPEND and RDEPEND only into ROOT. > There would be a flag --install-depend with the 3 settings described below > (host,root,both, default being root). Maybe it's clearer if we call it "target" instead of "root". Also, I think that name of the option should refer to "build-time" rather than "depend", since "depend" is rather ambiguous. > When HDEPEND gets implemented, this flag should be removed from emerge. I would suggest to keep the flag and have it apply to ebuilds using older EAPIs, while ebuilds using newer EAPIs would be unaffected by the flag. This is the approach taken in the patch that's attached to bug #317337, and it has the advantage that it won't break people's existing builds system (like that used by chromium-os devs).
(In reply to comment #3) > (In reply to comment #2) > > After discussion in bug #317337 - IMO DEPEND and RDEPEND should affect ROOT > > by default. > > This is what --root-deps does. Changing the default behavior (without > --root-deps option) is not friendly to existing users (like the chromium-os > devs), since it can break their build system, so we won't be doing that. > It's easy enough to add new options that toggle the desired behavior changes. But ain't this exactly what the suggested? Adding HDEPEND to allow to specify which deps need to be installed into / as opposed to ROOT? > > The defaults would hence be to install DEPEND and RDEPEND only into ROOT. > > There would be a flag --install-depend with the 3 settings described below > > (host,root,both, default being root). > > Maybe it's clearer if we call it "target" instead of "root". Also, I think > that name of the option should refer to "build-time" rather than "depend", > since "depend" is rather ambiguous. The idea with the flag name was to resemble the ebuild variable. Hence DEPEND -> --install-depend. Naming the value "target" instead of "root" is fine with me. The idea was to resemble the name of the envvar ROOT, but in a cross compilation setting this is of course the same. > > When HDEPEND gets implemented, this flag should be removed from emerge. > > I would suggest to keep the flag and have it apply to ebuilds using older > EAPIs, while ebuilds using newer EAPIs would be unaffected by the flag. This > is the approach taken in the patch that's attached to bug #317337, and it > has the advantage that it won't break people's existing builds system (like > that used by chromium-os devs). Well, yes, that is saner — apply --install-depend onto to EAPIs which do not implement HDEPEND.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > After discussion in bug #317337 - IMO DEPEND and RDEPEND should affect ROOT > > > by default. > > > > This is what --root-deps does. Changing the default behavior (without > > --root-deps option) is not friendly to existing users (like the chromium-os > > devs), since it can break their build system, so we won't be doing that. > > It's easy enough to add new options that toggle the desired behavior changes. > But ain't this exactly what the suggested? Adding HDEPEND to allow to > specify which deps need to be installed into / as opposed to ROOT? Sorry, I was mixing up something there. crossdev (which is afaik the portage-cross-compilation tool everyone uses) enables --root-deps by default, which results in the behaviour I suggested being the current default. The actual current default, however, is what you described. However, I am not convinced, that the current behaviour is the simplemost one. See bug #317337 comment #31.
(In reply to comment #4) > The idea with the flag name was to resemble the ebuild variable. Hence > DEPEND -> --install-depend. Yes, but since the meaning of the DEPEND variable may change in a future EAPI (such as become split into HDEPEND and TDEPEND), I think it's much less ambiguous if the option name refers to "build-time" in some way. Maybe we could call it --install-bdeps ("bdeps" is consistent with the existing --with-bdeps option which is used to pull in DEPEND for binary packages). (In reply to comment #5) > However, I am not convinced, that the current behaviour is the simplemost > one. See bug #317337 comment #31. It doesn't matter what you or anyone else thinks of the current default behavior. The default behavior does not change, for compatibility with user's existing build systems.
(In reply to comment #6) > (In reply to comment #4) > > The idea with the flag name was to resemble the ebuild variable. Hence > > DEPEND -> --install-depend. > > Yes, but since the meaning of the DEPEND variable may change in a future > EAPI (such as become split into HDEPEND and TDEPEND), I think it's much less > ambiguous if the option name refers to "build-time" in some way. Maybe we > could call it --install-bdeps ("bdeps" is consistent with the existing > --with-bdeps option which is used to pull in DEPEND for binary packages). Sounds good to me.
I'm still not sure what should be done about stage1 bootstrapping. The current situation with packages involved in bootstrapping is: - Many of packages use DEPEND for dependencies which would normally go in ROOT. Think of DEPEND="${RDEPEND} some_build_tools". - Because currently DEPEND means /, during bootstrap packages in / satisfy DEPEND dependencies and allow bootstrap which would otherwise not be possible (cycles etc.). To be able to bootstrap packages ported to EAPI=4-hdepend, it seems it would go somehow like this: - When those packages are ported, most of the time by moving build tools (!) from DEPEND to HDEPEND, and leaving the reset of DEPEND (inc. libraries). - A switch --with-bdeps={host,target,both} is added to emerge which defines the semantic of DEPEND. This would affect *all* DEPENDs, not just EAPI=4-hdepend. - Catalyst calls emerge with --with-bdeps=host, to make DEPEND work on / even for EAPI=4-hdepend, and the bootstrap packages will behave exactly as they did before. Note that --with-bdeps=host does not change the semantic of old EAPI, since DEPEND there goes to / anyway. Is this acceptable? If so, I will proceed to implement --with-bdeps.
Actually I still think --with-bdeps is not sufficient. For example, the default behavior should probably be to keep "DEPEND means /" for old EAPI, but introduce "DEPEND means ROOT" for new EAPI. A single --with-bdeps doesn't cover this. Maybe there should be two flags - one to modify handling of old EAPI and one for new EAPI? Alternatively, what if we try to not complicate and just introduce flags for specific use cases, like --bootstrap, which would do the following: - old EAPI stays the same, i.e. DEPEND==/ - in new EAPI, meaning of DEPEND is changed from ROOT to /. I'm not really sure why anything more would be necessary? Why would you want DEPEND from old EAPI to go to both - can't you just fix the ebuilds once we have HDEPEND?
(In reply to comment #9) > Maybe there should be two flags - one to modify handling of old EAPI and one > for new EAPI? Ebuilds using the new EAPI should be unaffected by the --install-bdeps option, since the new EAPI should allow the dependencies to be specified such that no behavior modification is needed.
(In reply to comment #10) > (In reply to comment #9) > > Maybe there should be two flags - one to modify handling of old EAPI and one > > for new EAPI? > > Ebuilds using the new EAPI should be unaffected by the --install-bdeps > option, since the new EAPI should allow the dependencies to be specified > such that no behavior modification is needed. Ambroz idea was that the flag is still necessary in case of prefix builds. I have to read up on Gentoo/Prefix to say anything more educated, though.
(In reply to comment #11) > Ambroz idea was that the flag is still necessary in case of prefix builds. I > have to read up on Gentoo/Prefix to say anything more educated, though. If it's like the CROSS_HDEPEND thing, that it's a different kind of flag, and preferably would not be triggered by emerge command line options. Preferably, it would only be possible to toggle it via a profile setting, since the profile has to be configured for cross compiling anyway. Making it an emerge command line flag would be exposing it in the wrong place where it would be more likely to be misused.
Actually, --install-bdeps probably should be an profile setting rather than an emerge command line flag too. However, it's still a fundamentally different kind of flag from the CROSS_HDEPEND flag. The difference is that --install-bdeps changes the meaning of existing *DEPEND variables for older EAPIs, while the CROSS_HDEPEND flag will simply control whether or not cross deps get pulled in for EAPIs that support cross deps. One is a backward compatibility hack, and the other is a purposefully designed configuration parameter .
To clarify, discussion on this bug should be focused on the proposed --install-bdeps={host,target,both} option. Future EAPIs that will make this option obsolete are mostly irrelevant to the discussion, since this the purpose of this option is only to modify the behavior of existing EAPIs.
It seems HDEPEND needs to be controlled independently of DEPEND, and that an additional value would be useful: none. When portage is called from outside a Gentoo installation (as far as I understand that could mean a Gentoo/Prefix style setup), one does not want to install packages to somewhere outside of ROOT. Hence HDEPEND needs to go nowhere and must be assumed to always be satisfied.
