Re: [gentoo-portage-dev] [PATCH 0/3] Add cross-prefix support
On 06/17/2013 12:21 AM, Ruud Koolen wrote: > This patch series adds support for using a portage installed in one prefix > to build packages with a different prefix. > > The current portage has a single EPREFIX variable specifying both the prefix > of the portage installation, and the prefix of the packages portage is > building. This patch series splits it into two parts: the > portage.const.EPREFIX variable specifying the prefix of the portage > installation, used for constructing the PATH as well as the paths to files > belonging to a portage installation itself rather than a target root; and the > EPREFIX setting in config instances, specifying the prefix of the > to-be-built packages and being used for almost everything else. > > The EPREFIX config setting defaults to const.EPREFIX, but can be overridden > by the EPREFIX environment variable, as well as the emerge --prefix option. > This allows one to install systems with different prefixes using > `EPREFIX=/foo emerge @system`, though some unrelated changes need to happen > elsewhere first in order to make that a reality. > > Ruud Koolen (3): > Distinguish between portage prefix and package prefix > Based GLOBAL_CONFIG_PATH and DEPCACHE_PATH on portage prefix > Pick up EPREFIX environment variable > > bin/dispatch-conf |2 +- > bin/portageq |2 +- > pym/_emerge/actions.py |9 + > pym/_emerge/main.py|7 > pym/portage/_legacy_globals.py |3 +- > pym/portage/_sets/__init__.py |3 -- > pym/portage/const.py | 34 > ++-- > pym/portage/dispatch_conf.py |2 +- > .../package/ebuild/_config/LocationsManager.py | 22 - > pym/portage/package/ebuild/config.py | 21 > pym/portage/package/ebuild/doebuild.py |2 +- > pym/portage/package/ebuild/fetch.py|4 -- > pym/portage/tests/resolver/ResolverPlayground.py |3 +- > pym/portage/util/env_update.py |3 +- > 14 files changed, 34 insertions(+), 83 deletions(-) > I've committed your patches with a few trivial modifications, as noted here: http://bugs.gentoo.org/show_bug.cgi?id=395633#c37 -- Thanks, Zac
RE: [gentoo-portage-dev] [PATCH 0/3] Add cross-prefix support
On Mon, 17 Jun 2013, at 01:00, Ruud Koolen thusly quipped: > I also didn't test whether these patches work on the prefix-portage branch. I > don't really know much far prefix-portage diverges from mainline portage, so I > don't know whether I should expect it to just work. Prefix portage is literally a branch -- in the git sense of the term -- of the regular portage git repo on g.o.g.o. So, a good place to start is to check out that branch and see if your diffs apply. When I am doing work that I expect to flow into both branches, I typically maintain a "master" and prefix_master private branch, with the latter set to pull from origin/prefix, i.e.: [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = /usr/src/repos/git/portage.git [branch "master"] remote = origin merge = refs/heads/master [branch "prefix_master"] remote = origin merge = refs/heads/prefix [branch "cygwin_master"] remote = . merge = refs/heads/prefix_master Guess I didn't use very consistent naming. The basic plan is, with the arrows representing flows of information to the right-hand side on "git pull": [upstream repo] -> /usr/src/repos/git/portage.git -- a bare, vanilla clone of upstream [portage.git/master] -> master (which is a private branch with upstreamable patches) [portage.git/prefix] -> prefix_master (also a private branch, analogous to master, with forward-ported versions of my patches in master; upstreamable to "origin/prefix") [prefix_master] -> cygwin (an experimental prefix portage "fork", downstream to all of the above) Usually I cherry-pick patches from master into prefix_master and perform up any merges at that phase, and then just "git checkout cygwin ; git pull" to merge those (vs.-vanilla-prefix-portage) patches into my experimental prefix portage fork. I do that way because my eyes simply glaze over when I try to read that whole business about prune-and-graft in git merge --help; however if you end up with a huge pile of patches to merge, the prune-graft approach should work perfectly fine to move deltas from master to prefix-master. -gmt
Re: [gentoo-portage-dev] [PATCH 0/3] Add cross-prefix support
On Monday 17 June 2013 09:53:11 Fabian Groffen wrote: > Hi Ruud, > > Thanks so much for your work. I hope to have a look at this soon, and > merge this. From your work I assume your patches don't "break" normal > installs/bootstraps, right? (You tested that?) > > Fabian I tested emerge -e @world on both gx86 and prefix, and the ability to cross-eprefix build packages. I did not test bootstrapping. I also didn't test whether these patches work on the prefix-portage branch. I don't really know much far prefix-portage diverges from mainline portage, so I don't know whether I should expect it to just work. -- Ruud
Re: [gentoo-portage-dev] [PATCH 0/3] Add cross-prefix support
Hi Ruud, On 17-06-2013 09:21:41 +0200, Ruud Koolen wrote: > This patch series adds support for using a portage installed in one prefix > to build packages with a different prefix. Thanks so much for your work. I hope to have a look at this soon, and merge this. From your work I assume your patches don't "break" normal installs/bootstraps, right? (You tested that?) Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
[gentoo-portage-dev] [PATCH 0/3] Add cross-prefix support
This patch series adds support for using a portage installed in one prefix to build packages with a different prefix. The current portage has a single EPREFIX variable specifying both the prefix of the portage installation, and the prefix of the packages portage is building. This patch series splits it into two parts: the portage.const.EPREFIX variable specifying the prefix of the portage installation, used for constructing the PATH as well as the paths to files belonging to a portage installation itself rather than a target root; and the EPREFIX setting in config instances, specifying the prefix of the to-be-built packages and being used for almost everything else. The EPREFIX config setting defaults to const.EPREFIX, but can be overridden by the EPREFIX environment variable, as well as the emerge --prefix option. This allows one to install systems with different prefixes using `EPREFIX=/foo emerge @system`, though some unrelated changes need to happen elsewhere first in order to make that a reality. Ruud Koolen (3): Distinguish between portage prefix and package prefix Based GLOBAL_CONFIG_PATH and DEPCACHE_PATH on portage prefix Pick up EPREFIX environment variable bin/dispatch-conf |2 +- bin/portageq |2 +- pym/_emerge/actions.py |9 + pym/_emerge/main.py|7 pym/portage/_legacy_globals.py |3 +- pym/portage/_sets/__init__.py |3 -- pym/portage/const.py | 34 ++-- pym/portage/dispatch_conf.py |2 +- .../package/ebuild/_config/LocationsManager.py | 22 - pym/portage/package/ebuild/config.py | 21 pym/portage/package/ebuild/doebuild.py |2 +- pym/portage/package/ebuild/fetch.py|4 -- pym/portage/tests/resolver/ResolverPlayground.py |3 +- pym/portage/util/env_update.py |3 +- 14 files changed, 34 insertions(+), 83 deletions(-) -- 1.7.2.5
