Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 137446 - PORTAGE_CONFIGROOT breaks compile-time dependencies
Summary: PORTAGE_CONFIGROOT breaks compile-time dependencies
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS
Depends on:
Blocks: 137867 136244
  Show dependency tree
 
Reported: 2006-06-20 17:23 UTC by James Le Cuirot
Modified: 2006-07-05 11:26 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Le Cuirot gentoo-dev 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 gentoo-dev 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 gentoo-dev 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 gentoo-dev 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 gentoo-dev 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 gentoo-dev 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 gentoo-dev 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 gentoo-dev 2006-07-04 19:49:18 UTC
This is fixed in svn r3785.
Comment 8 Zac Medico gentoo-dev 2006-07-05 11:26:03 UTC
This has been released in 2.1.1_pre2-r3.