Too verbose to describe well in the title. In all in-tree versions of the named package, the following command is ran: PORTAGE_CONFIGROOT="${CHILD_EPREFIX}" EPREFIX="${CHILD_EPREFIX}" emerge -1qO \ gentoo-functions baselayout-prefix gnuconfig prefix-chain-utils the problem is, for example, if you set CHILD_EPREFIX to /usr/i686-w64-mingw32, packages end up being installed to /usr/i686-w64-mingw32/usr/i686-w64-mingw32 which is on its face wrong, and cannot be anything otherwise because both variables are unconditionally set to the value of CHILD_EPREFIX.
Erm, PORTAGE_CONFIGROOT is where portage (emerge) does read its configuration from, and EPREFIX is where packages are installed into. Which underlying OS are you running on - Linux (which one?) or Cygwin, and where do you use portage from (Gentoo Linux or Gentoo Prefix)? To actually be able to help here I need to be able to reproduce your issue. Another thought is: MinGW usually is supported via crossdev, but I'm not sure how well that one already plays together with Prefix...
One more bit: This requires prefix portage to be merged with USE=prefix-chaining. I've added this dependency to app-portage/prefix-chain-setup-0.7.ebuild.
(In reply to Michael Haubenwallner from comment #1) > Erm, PORTAGE_CONFIGROOT is where portage (emerge) does read its > configuration from, and EPREFIX is where packages are installed into. > > Which underlying OS are you running on - Linux (which one?) or Cygwin, and > where do you use portage from (Gentoo Linux or Gentoo Prefix)? > > To actually be able to help here I need to be able to reproduce your issue. > > Another thought is: MinGW usually is supported via crossdev, but I'm not > sure how well that one already plays together with Prefix... I'm currently running on a stock stage3-amd64-yyyymmdd.tar.bz2 based install, and my portage is from ::gentoo Yes, the mingw-w64 toolchain is created by/maintained by crossdev; I'm just looking into ways one can cleanly install some packages which require stuff like sys-apps/sed, sys-apps/coreutils and whatnot, and its my understanding that using a prefix chain can allow packages in the child prefix use deps from the parent. (In reply to Michael Haubenwallner from comment #2) > One more bit: > This requires prefix portage to be merged with USE=prefix-chaining. > I've added this dependency to app-portage/prefix-chain-setup-0.7.ebuild. Interesting. I take it this is not the stock ::gentoo sys-apps/portage? imho it would be ideal if this worked even for not-prefix'd portage, for cases like mine.
Also, I notice you changed the title into 'installs into CHILD_PREFIX', this is incorrect. It installs into 'CHILD_PREFIX/CHILD_PREFIX'
(In reply to hanetzer from comment #3) > > One more bit: > > This requires prefix portage to be merged with USE=prefix-chaining. > > I've added this dependency to app-portage/prefix-chain-setup-0.7.ebuild. > > Interesting. I take it this is not the stock ::gentoo sys-apps/portage? Yes: In Prefix we do have a different tree - the "prefix tree", which is a combination of the "gentoo tree" plus the "prefix overlay" - where "prefix overlay" content overrides "gentoo tree" content (with content=packages+eclasses). > imho it would be ideal if this worked even for not-prefix'd portage, for cases > like mine. Yes, but we're not there yet. However, using your "Gentoo Linux" host system you might make more mileage when you replace "sys-apps/portage::gentoo-tree" with "sys-apps/portage::prefix-overlay" (with USE=prefix-chaining) there. The latter should still be able to manage your host system as well!
(In reply to Michael Haubenwallner from comment #5) > (In reply to hanetzer from comment #3) > > > One more bit: > > > This requires prefix portage to be merged with USE=prefix-chaining. > > > I've added this dependency to app-portage/prefix-chain-setup-0.7.ebuild. > > > > Interesting. I take it this is not the stock ::gentoo sys-apps/portage? > > Yes: In Prefix we do have a different tree - the "prefix tree", which is a > combination of the "gentoo tree" plus the "prefix overlay" - where "prefix > overlay" content overrides "gentoo tree" content (with > content=packages+eclasses). > > > imho it would be ideal if this worked even for not-prefix'd portage, for cases > > like mine. > > Yes, but we're not there yet. > However, using your "Gentoo Linux" host system you might make more mileage > when you replace "sys-apps/portage::gentoo-tree" with > "sys-apps/portage::prefix-overlay" (with USE=prefix-chaining) there. > The latter should still be able to manage your host system as well! Where is the exact location of this overlay? I find https://gitweb.gentoo.org/repo/proj/prefix.git/tree/ but its lacking metadata/layout.conf and profiles/repo_name which are needed for use via repos.conf and the like.
and... sys-apps/portage::prefix-overlay is busted, haubi I'm going to need some help here. a lot of apparent placeholder variables did not get fixed up.
can you paste some errors or warnings you see?
Ah - prefix-overlay cannot be used without prefix portage already installed... Probably, "user patches" may help you here: In particular, put the prefix.patch into /etc/portage/patches/sys-apps/portage/ and remerge your host portage first. Then add prefix-overlay - using oldstyle PORTDIR_OVERLAY does not require the additional metadata...
The "prefix.patch" is the difference between branch master and prefix in https://gitweb.gentoo.org/proj/portage.git/
(In reply to Fabian Groffen from comment #8) > can you paste some errors or warnings you see? stuff like @PORTAGE_BASH@: bad interpreter and whatnot. I managed to hax my way back to a working, usable portage. (In reply to Michael Haubenwallner from comment #9) > Ah - prefix-overlay cannot be used without prefix portage already > installed... > > Probably, "user patches" may help you here: In particular, put the > prefix.patch into /etc/portage/patches/sys-apps/portage/ and remerge your > host portage first. > Then add prefix-overlay - using oldstyle PORTDIR_OVERLAY does not require > the additional metadata... Ah, well how do I get said patch from gitweb? I'm not particularly used to that interface. (In reply to Michael Haubenwallner from comment #10) > The "prefix.patch" is the difference between branch master and prefix in > https://gitweb.gentoo.org/proj/portage.git/ Gotcha.
Ok, that feels like a wrongly installed ebuild. Are you aware we have our own rsync servers? You can browse them manually via http://rsync.prefix.bitzolder.nl/ as well as rsync off of them, you get the regular gentoo tree overlaid with our changes as haubi mentioned in comment #5.
(In reply to Fabian Groffen from comment #12) > Ok, that feels like a wrongly installed ebuild. > > Are you aware we have our own rsync servers? You can browse them manually > via http://rsync.prefix.bitzolder.nl/ as well as rsync off of them, you get > the regular gentoo tree overlaid with our changes as haubi mentioned in > comment #5. Yes, but as far as I can tell the same issue would exist for that tree. Apparently EPREFIX="" so none of the processing is actually happening. I've tried EPREFIX="/" ebuild /path/to.ebuild install, but the ./image/ directory tree still has all the old references to @PORTAGE_BASH@ and whatnot.