In previous conversations, I've always called this REALROOT, so that's what I'll refer to it as here. Although I don't really care what it's called. Basically, I'd like to see a new variable created that acts like ROOT but uses more of the config files from ROOT instead of /. Personally I'd like to see the following from ROOT: /etc/make.conf /etc/portage/* /etc/make.profile /etc/make.globals Reproducible: Always Steps to Reproduce: 1. 2. 3. I had a patch here that was about 8 lines that did /etc/make.conf from REALROOT. I understand that the others will probably be fairly difficult.
I've been working on something similar. the attached patch is what I'm at right now (ie not a pretty view) I've used GENTOOROOT as a variable to decide what should be the root of the gentoo installation and configuration files. the goal of these changes is to be able from a modified portage and a basic tree layout to install gentoo in a user home directory without any priviledges. of course some libs from the host system have to be used.
Created attachment 45277 [details] an attempt at making portage install gentoo in a user home directory
*** This bug has been marked as a duplicate of 92593 ***
sorry, wrong way :\
*** Bug 92593 has been marked as a duplicate of this bug. ***
I've been looking at the patch and it's way too complex to be accepted. Could the original author, please, modify it to change ONLY the ROOT-related stuff (get rid of the formatting and other extra chnages)? Thanks... To the portage-dev team: Could you, please, look at that? It can't be that hard to implement...
It really is harder than you think. It's not just changing some of the constants. One of the portage devs told me the gory details once, but I don't even remember enough of it to be useful. Either ask one of them to explain it (I think it was jstubbs that told me), or take my word for it. They do have plans to work on this, but there are more important things to do first. Now for some help on your original problem... See vapier's HOWTO crosscompile (http://dev.gentoo.org/~vapier/CROSS-COMPILE-HOWTO) It tells you what you need to set on the command line to get cross compiling going. (it's step 9 at the bottom)
s/more important/prerequisite/
well..., the patch was a work in progress, and unfortunately still is since I stopped working on it a while ago. Plus it's not 100% what the submitter was trying to achieve. My goals were to be able to emerge gentoo packages (as a regular user) inside a minimal environment eventually using some of the installed libraries on the system. Looking at it after almost six month, only the first files of the patch are relevant, that is modifying the shell scripts to include CONFIGROOT (GENTOOROOT in the patch) after ${D}. This part was easy, the problems were found in the ebuild themselves (don't remember exactly but for example not all of them were using dodoc to install or used it with different base path) not all ebuild use econf too... In the end I ended up being able to compile some packages as a non-root user, but the process was flaky to say the least... To fix everything and make it work with gentoo quality is really difficult and some things (imho cleaning portage design, and enforcing more conventions inside ebuilds) are needed first.
I agree that cleaning up portage first would be cool but I can't see anyone working on that so we could end up waiting forever... :-( I think it would be cool to include it now but leave it as "not-supported" so people who need it can play with it... My reason why I need this is not a rootless install but a complete cross-compile/remote-compile install. I don't have much disk space on host B so I don't want a compiler nor portage to be installed there. Everything will be on host A which will just issue "REALROOT=/nfsmount emerge system" or something like this...
There's nothing stopping you from using the patch on this bug. There is no such thing as adding something unsupported to portage. As soon as it's added, it becomes expected to be supported for years beyond its life. Anyway, this bug is still open (and is still as young as 6 months) and will be implemented in one way or another down the track.
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
I override settings from /etc/make.conf in the local environment, I use the same profile on all machines, but I needed to have per-ROOT package.* files. Hence the following obscenity : --- pymportage.py 2006-03-19 22:51:58.000000000 +1100 +++ ../portage-2.1_pre6-r3/work/portage-2.1_pre6/pym/portage.py 2006-03-19 21:22:41.000000000 +1100 @@ -126,8 +126,6 @@ sys.exit(127) -USER_CONFIG_PATH = USER_CONFIG_PATH + "." + os.environ["MACHINE_NAME"] - # =========================================================================== # END OF IMPORTS -- END OF IMPORTS -- END OF IMPORTS -- END OF IMPORTS -- END # =========================================================================== Define MACHINE_NAME and put your config files in /etc/portage.$MACHINE_NAME Appears to work, limited testing thus far.
Jonathan, Hows that testing going?
Some thoughts: MACHINE_NAME must be set in the local environment, not make.conf (as it has not been getconfig'd by the time MACHINE_NAME is used in the patch as it stands). The added line [not the removed one - I got the patch backwards] could probably be put elsewhere to compensate for this - from a naive perusal, right after getconfig(MAKE_CONF_FILE) in portage.py would probably do the trick - it seems that USER_CONFIG_PATH is not used (at least in config's __init__) before this point. And then os.environ will probably not be the correct way to access it. If it must be set earlier, /etc/env.d would be the place to make it happen. If MACHINE_NAME is not set, some less braindead behaviour would be useful - for example not barfing ;). (I guess it could be set to "" in portage_const.py and then imported...) Also, USER_CONFIG_PATH should remain /etc/portage/, not /etc/portage./ if MACHINE_NAME="" I have been using MACHINE_NAME="local" for the 'host' system and symlinking /etc/portage.local -> /etc/portage (not ideal) I did have one case where running etc-update without MACHINE_NAME set (I think) removed the contents of /etc/portage/. It ran fine when MACHINE_NAME was correctly set. Those are the minor (heh) but generally surmountable problems I've had (so far). Other than these, I have had some success using this method for per-ROOT package.* files. Management of per machine settings seems a little complicated with this approach {and I think it always will be, even with a full CONFIGROOT type solution). It does solve the problems I've had - I can override anything from /etc/make.conf in the environment, and all of the package.* files can be overridden successfully with this method. This will not solve the need to change /etc/make.profile for different settings of ROOT, but that is not a problem I have had to deal with (yet). Ideally (imho) it would be good to move /etc/make.* into /etc/portage/ and then be able to vary where portage looks for settings (using something like CONFIGROOT). There are lots of good reasons why this can't/won't happen.
Reopening bug. This is a vital feature.
I'm ready to start adding support for this. Is PORTAGE_CONFIGROOT a good name for the variable? I prefer of portage variables to begin with PORTAGE_ in order to avoid name clashes...
You doing this in 2.1, or 2.2? Cause 2.1 really could stand to be finished and released...
(In reply to comment #18) > Cause 2.1 really could stand to be finished and released... Yes. However, this feature seems simple enough to implement. As an added bonus, it will make it easier to run portage from an arbitary location in the filesystem (similar to the prefix branch, in a way). I plan to exploit this particular feature in the server side metadata cache generation on osprey. That way the cache generation can be independent and decoupled from the version of portage that is installed on the server (much more elegant than having them bound together).
I've added initial support for PORTAGE_CONFIGROOT in svn r3291. It includes support or ${PORTAGE_CONFIGROOT}/etc/make.* and ${PORTAGE_CONFIGROOT}/etc/portage/. When unset, the default value for PORTAGE_CONFIGROOT is /.
Released in 2.1_pre10-r1.
*** Bug 40302 has been marked as a duplicate of this bug. ***
thank you Zac!!
