Bug 137446 – PORTAGE_CONFIGROOT breaks compile-time dependencies

• Product: Portage Development
• Status: RESOLVED FIXED

[Description James Le Cuirot 2006-06-20 17:23:03 UTC]

Normally when using ROOT, any compile-time dependencies get installed to / rather than ROOT. This is fine when ROOT has a similar make.conf to / but problems arise when they differ and PORTAGE_CONFIGROOT is given. $PORTAGE_CONFIGROOT/etc/make.conf gets used instead of /etc/make.conf when building the dependency to be installed to /. The result is that the wrong CFLAGS and possibly even the wrong compiler are used. I suppose make.conf should be re-read when switching between / and ROOT but this would probably cause other problems.

[Comment 1 Zac Medico 2006-06-21 00:31:38 UTC]

(In reply to comment #0)
> building the dependency to be installed to /. The result is that the wrong
> CFLAGS and possibly even the wrong compiler are used. I suppose make.conf
> should be re-read when switching between / and ROOT but this would probably
> cause other problems.

emerge and some of portage.py are still dependent on lots of global variables.  Once we've gotten the globals cleaned up this should be possible.  I've got some emerge refactoring on my near-future todo list, so I'll definitely keep this issue in mind when I do that.

[Comment 2 Zac Medico 2006-06-30 03:30:37 UTC]

I've made lots of progress refactoring and cleaning up the globals.  The way that I imagine this working is that emerge will have a separate portage.config instance that represents PORTAGE_CONFIGROOT="/".  It will also have a separate binary package database corresponding to $PKGDIR from that config instance.  The portage tree database can be shared by both, but it's matching behavior will vary depending on which config instance is being used at the time.

[Comment 3 James Le Cuirot 2006-06-30 03:40:45 UTC]

I don't know much about the internals of Portage but I assume portage.config holds the data read from make.conf and maybe /etc/portage. Sounds good to me anyway. (-:

[Comment 4 Zac Medico 2006-07-03 00:37:20 UTC]

(In reply to comment #3)
> I don't know much about the internals of Portage but I assume portage.config
> holds the data read from make.conf and maybe /etc/portage.

That's correct.

(In reply to comment #2)
> The portage tree database can be shared by both, but it's matching behavior
> will vary depending on which config instance is being used at the time.

I've changed my mind about this.  For symmetry, we should honor the PORTDIR (and PORTDIR_OVERLAY) for each config instance.  Therefore, there will be a separate portage tree for each config.  The portage internals are sort of designed for this approach anyway, where portage.db["/"]["porttree"] and portage.db[portage.settings["ROOT"]]["porttree"] are separate.  However, until PORTAGE_CONFIGROOT was added, there was no way to have a separate config for each.

[Comment 5 James Le Cuirot 2006-07-03 03:07:28 UTC]

I can understand why you might want to keep them separate but I would probably just mount --bind them anyway.

[Comment 6 Zac Medico 2006-07-03 14:15:42 UTC]

(In reply to comment #5)
> I can understand why you might want to keep them separate but I would probably
> just mount --bind them anyway.

Just to clarify, you won't need to bind mount. You would use simply use the same PORTDIR path in both /etc/make.conf and $PORTAGE_CONFIGROOT/etc/make.conf.

[Comment 7 Zac Medico 2006-07-04 19:49:18 UTC]

This is fixed in svn r3785.

[Comment 8 Zac Medico 2006-07-05 11:26:03 UTC]

This has been released in 2.1.1_pre2-r3.