Summary: | Portage chooses virtuals from base system, not ROOT | ||
---|---|---|---|
Product: | Portage Development | Reporter: | James Le Cuirot <chewi> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | radek |
Priority: | High | Keywords: | InVCS |
Version: | 2.1 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 137867, 136244 |
Description
James Le Cuirot
2006-04-26 04:51:00 UTC
${ROOT}/etc/make.profile is not something we want portage todo. I see that alternative options were discussed in bug #73350 and you seem to support them since you said it was a "vital feature". But regardless of how that bug is tackled, I think this is still an issue. Just to clarify my last point, imagine you are creating a ROOT system that has the same architecture as the base system. You wouldn't expect the packages installed on the base system to influence which packages are chosen for the ROOT system. For example, if you install suspend2-sources on the base system, you would still expect "emerge linux-sources" to select gentoo-sources for the ROOT system. The host systems virtuals are used as a preference. Consider the following example using an older portage-2.1_preX: ROOT=~/ROOT/ rm -rf ${ROOT} mkdir -p ${ROOT} ACCEPT_KEYWORDS="x86" emerge gcc -pv Notice how it incorrectly attempts to pull in eselect-compiler vs gcc-config and you can't merge it cuz it's not marked stable. this is how the || ( ) worked before. Now the only way to correct the preference of virtuals is to preload them. Having a CONFIGROOT= would indeed allow you to override these to your endless desires. Someone in #gentoo-embedded suggested that and I suppose he had a point, this is one of the many issues that falls under that bug. However, I feel that fixing this particular issue would be much easier than fixing the rest of it and it would offer some immediate benefits. I have no way of telling, short of checking on a package by package basis, whether the virtuals that are being installed in my new ROOT system are actually the default choices. It seems that blockers are also picked up from the base system instead of from ROOT. schwartz ~ # emerge-ps2 -pv ps2-headers * Redirecting hostfs Portage environment to rootfs ... [ ok ] These are the packages that would be merged, in order: Calculating dependencies... done! [blocks B ] sys-kernel/linux-headers (is blocking sys-kernel/ps2-headers-2.4.17) [ebuild N ] sys-kernel/ps2-headers-2.4.17 to /mnt/br/gentoo/ 0 kB Total size of downloads: 0 kB * Restoring hostfs Portage environment ... [ ok ] * Restoring rootfs Portage environment ... [ ok ] >>> Regenerating /mnt/br/gentoo/etc/ld.so.cache... schwartz ~ # emerge-ps2 -C linux-headers * Redirecting hostfs Portage environment to rootfs ... [ ok ] >>> Using system located in ROOT tree /mnt/br/gentoo --- Couldn't find linux-headers to unmerge. >>> No packages selected for removal by unmerge. * Restoring hostfs Portage environment ... [ ok ] * Restoring rootfs Portage environment ... [ ok ] >>> Regenerating /mnt/br/gentoo/etc/ld.so.cache... Well I have now switched from using the rmerge script to using the new PORTAGE_CONFIGROOT feature but this is still an issue. root@schwartz # emerge-ps2 -upD system These are the packages that would be merged, in order: Calculating system dependencies... done! [blocks B ] sys-kernel/linux-headers (is blocking sys-kernel/ps2-headers-2.4.17) [blocks B ] sys-apps/module-init-tools (is blocking sys-apps/modutils-2.4.27-r1) [ebuild U ] dev-lang/python-2.4.3-r1 [2.4.2-r1] to /mnt/gentoo-ps2/ USE="-nocxx*" [ebuild U ] sys-apps/sandbox-1.2.18 [1.2.17] to /mnt/gentoo-ps2/ [ebuild U ] app-misc/pax-utils-0.1.12 [0.1.11-r1] to /mnt/gentoo-ps2/ [ebuild N ] sys-process/psmisc-22.2 to /mnt/gentoo-ps2/ USE="-X -ipv6 -nls" [ebuild N ] sys-apps/busybox-1.1.2 to /mnt/gentoo-ps2/ USE="-debug -floppyboot -make-symlinks -netboot -savedconfig -static" [ebuild N ] sys-apps/kbd-1.12-r6 to /mnt/gentoo-ps2/ USE="-nls" I'm pretty sure this is fixed in svn r3785. It needs testing though. This has been released in 2.1.1_pre2-r3. Please test and reopen if there are any remaining issues. |