Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 87877 - let portage work in different PREFIX, with packages to install in new PREFIX too
Summary: let portage work in different PREFIX, with packages to install in new PREFIX too
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Portage team
: 6474 (view as bug list)
Depends on:
Reported: 2005-04-04 00:58 UTC by Michael Haubenwallner
Modified: 2007-01-11 14:49 UTC (History)
8 users (show)

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

add possibility to install and run portage within /usr/local (portage-affix.patch,439.77 KB, patch)
2005-04-04 01:23 UTC, Michael Haubenwallner
Details | Diff
fix two bugs in previous patch to get it work (portage-affix-2.patch,1.58 KB, patch)
2005-04-04 23:49 UTC, Michael Haubenwallner
Details | Diff
now able to re-install portage with an ebuild keeping user/group-settings; some other fixes (portage-affix-3.patch,49.97 KB, patch)
2005-04-07 05:09 UTC, Michael Haubenwallner
Details | Diff
collection of previous patches, updated agains current cvs (portage-affix-4.patch,362.51 KB, patch)
2005-04-15 06:16 UTC, Michael Haubenwallner
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Haubenwallner gentoo-dev 2005-04-04 00:58:48 UTC
Assume you want portage to be installed into /usr/local, or even /opt/portage:
1) This does not work (autotoolizing-problems)
2) When installed so, portage itself does not use this path for finding cache...
3) When emerging packages, these should be configured with --prefix=/usr/local

All this is to ease the use of portage on non-Gentoo-Linux systems.

Reproducible: Always
Steps to Reproduce:
Comment 1 Michael Haubenwallner gentoo-dev 2005-04-04 01:23:22 UTC
Created attachment 55252 [details, diff]
add possibility to install and run portage within /usr/local

So try:
# ./configure --prefix=/tmp/haubi
# make
# make install
Then put a portage-tree into /usr/local/portage,
create the /usr/local/etc/make.conf file,
create the /usr/local/etc/make.profile softlink,
and then try:
# /usr/local/bin/emerge --help
# /usr/local/bin/emerge -av patch
# PREFIX=/opt/portage [ROOT=/tmp/haubi] /usr/local/bin/emerge -av patch

Do an strace on this or do within a sandboxshell, and you will see no
access to /var/cache/edb/...
Comment 2 Michael Haubenwallner gentoo-dev 2005-04-04 23:49:49 UTC
Created attachment 55331 [details, diff]
fix two bugs in previous patch to get it work
Comment 3 Michael Haubenwallner gentoo-dev 2005-04-07 05:09:34 UTC
Created attachment 55550 [details, diff]
now able to re-install portage with an ebuild keeping user/group-settings; some other fixes

  07 Apr 2005; <>, acinclude.m4,
  bin/ebuild, cnf/,, pym/,
  pym/, src/filter-env/, -src/filter-env/getopt.c,
  -src/filter-env/getopt.h, src/filter-env/posix.c:
  creation of subst-install.vars works with non-bash too now.
  check for existance of getopt.h instead of providing myself.
  use portage_const.MYROOT in bin/ebuild too.
  environment variables, to upgrade with portage.ebuild keeping these names.
Comment 4 Ciaran McCreesh 2005-04-07 06:51:48 UTC
Here's the main problem... See, if you install, say, vim to /usr/local, we have to update the eclass to tell vim to look in /usr/local for runtime files. But then, what if vim-core is installed to /usr? And say we install vim to /opt/gentoo, do we even want it to look in /usr for runtime files -- maybe there're some crippled runtime files that we shouldn't use that've been installed by another operating system in /usr.

Don't try to dismiss this as "a few ebuilds will need changing" either. It's not "a few". I didn't even get started on the whole linking thing :)
Comment 5 Michael Haubenwallner gentoo-dev 2005-04-08 01:36:36 UTC
sorry for the long explanation...

Seems my example is misunderstandable, at least due to this bug:
-# ./configure --prefix=/tmp/haubi
+# ./configure --prefix=/usr/local

The use of "PREFIX=/opt/portage emerge ..." is intended to _just bootstrap_ a
portage-instance into /opt/portage from the already running one in /usr/local
or even /usr, much like "ROOT=/tmp/image/ emerge ..." does right now, but
without the need to chroot to /tmp/image afterwards: it creates a completely
new /opt/portage/var/{db/pkg,cache/edb}

Anyway: you can use "ROOT=/tmp/image/ PREFIX=/opt/portage emerge ..." too,
and when using just "ROOT=/tmp/image/ emerge ..." the prefix is the same
as the used portage is installed into.

Once you've a running portage-instance in /opt/portage/, use
/opt/portage/bin/emerge to merge world into /opt/portage, so you don't have
different prefixes for several packages within one portage instance.

The "./configure --prefix=/usr/local" is just to ease bootstrapping portage
in case of non-Gentoo systems, and to be used within the >=portage-2.1.ebuild
You get a complete /usr/local/var/{db/pkg,cache/edb} here too.

And for the .ebuild-changes: Think of it as a new userland/arch/whatever:
in any case there _is_ a new KEYWORD required to mark an .ebuild as

It is not defined yet how to name the new keyword, but even GLEP 22
is not fully implemented yet. For now, i use keywords like "x86-linux",
"sparc-solaris", "hppa-hpux", "ia64-hpux" and the like within my portage-tree.

Maybe there should be one keyword like "embedded" or "prefix" ANDed with
the ARCH keyword or the like... -> subject for #gentoo-portage soon...

Additionally, i've added a USERLAND called "UNIX" by now, as it seems
that HP-UX/AIX/SunOS are very close to each other. But maybe i have
to add a separate userland for each of them.

What are the benefits of installing into different prefixes:
*) You can easy maintain the GNU-things in case of a non-GNU Unix
*) To guarantee stability you can install severall stable-trees (GLEP 19) on
the same machine and have a few users to test the new one without breaking
the others.
*) You can easily test new versions of packages within the same slot without
have to chroot and install the whole thing, just inject/provide the depencies.
*) You can easily create a Gentoo-Stage0 on a non-Gentoo-Linux by using
"ROOT=/tmp/stage0/ PREFIX=/usr emerge ..." with a portage-instance in
*) ...
Comment 6 Michael Haubenwallner gentoo-dev 2005-04-15 06:16:18 UTC
Created attachment 56350 [details, diff]
collection of previous patches, updated agains current cvs

this patch also contains this:
portage_util.writemsg is imported into pym/ (ferringb knows
Comment 7 Michael Haubenwallner gentoo-dev 2005-04-20 02:45:05 UTC
Well, here's another try to describe the ideas behind this:

When i get a fresh SunOS/AIX/HP-UX/non-GNU machine, it is quite unusable
unless i install many GNU packages, like findutils/bash/gcc/python/perl/...

And i don't want to install them into /usr and /, but into /usr/local
or /home/haubi or /opt/gnu.
It's a pain to manage (remove/upgrade) those packages without a pkg-manager,
so why not use portage to do this ?

And why not manage my own packages with portage too ?

So first i install portage-depencies (bash/python) somewhere into my PATH
(can already be /opt/gnu), then portage into /opt/gnu (configured with
--prefix=/opt/gnu), and then use this portage to install the other packages
into /opt/gnu (including bash/python and portage again to enforce it to use
/opt/gnu/bin/{bash,python}, called bootstrapping).

The use of "PREFIX=/another/prefix emerge ..." is just to _bootstrap_
another prefix from an already running portage instance, _not_ to give every
package a new prefix.

Another use-case is to have multiple (stable, GLEP 19) instances of packages
installed on one system, let users choose one of them by sourcing the right

And while upgrading packages within a prefix, it is likely that this prefix
is broken while upgrading, so why not install fresh into another prefix ?
Comment 8 Ciaran McCreesh 2005-04-20 05:14:59 UTC
Comment 9 Lina Pezzella (RETIRED) gentoo-dev 2005-04-20 06:02:47 UTC
Mmmmm, yes. I hope you're not waiting on Pieter to put forth his implementation when Michael Haubenwallner here has just gone ahead and done it without all the talk... Perhaps we could 
Comment 10 Ciaran McCreesh 2005-04-20 06:14:40 UTC
No, this isn't pathspec. It's an attempt to implement pathspec without actually knowing the requirements or getting the implementation side of it correct, and without solving the "we can't modify the entire tree" issue.
Comment 11 Michael Haubenwallner gentoo-dev 2005-04-21 00:13:22 UTC
googled out what you mean with "pathspec", last not least found on your "random
gentoo" site.

Why just install into /opt/gentoo ?
Well, ${HOME} is a special thing, but if one decides to do, why block ?

It _is_ impossible to get pathspec work without the need for chroot if you
want to avoid slightly modifying ebuilds. You do _not_ have to modify
all ebuilds at once, but gradual those you want to install besides / and /usr.
You _have_ to modify ebuilds for every new platform/keyword right now too, so
this cannot be the problem.
And - modified ebuilds _continue_ to work for / and /usr.

... unless there's found one to do this job.

IMO "pathspec" does not intend to install several _packages_ into different 
prefixes, but have several _installations_ (or how to call these), each with
one portage running, in different prefixes (versioned,...) on one machine.

My patch here is just one (big) step to get first) and second) and third:) to
work cleanly, nothing more, at least the GLEP 22 problem is still not solved.
Comment 12 Ciaran McCreesh 2005-04-21 00:18:11 UTC
The first step is figuring out how this will work *from an ebuild perspective*. Once that's agreed upon and documented, *then* start on the portage implementation.
Comment 13 Brian Harring (RETIRED) gentoo-dev 2005-05-08 01:24:47 UTC
Thus far, unless you reverse your opinions stated on the dev ml, affix/prefix covers the basic goal of this bug; discussion of the additional pathspec cruft (SUPPORTS metadata) is ongoing.

Re: having a patch first, it's a proof of concept, nothing more, nothing less.  Ironing out the concept (your vim plugins) is ongoing- meanwhile, slapping jason's list of issues/needs here- 

1  Portage needs to be enhanced with a new SUPPORTS so that packages can                                                                      
   specify that they can install into a non-standard location.                                                                                
2  Portage needs to be enhanced with new ebuild support functions for                                                                         
   detecting the location of a dependency.                                                                                                    
3  Portage needs to supply PREFIX and AFFIX variables to those ebuilds that                                                                   
   support non-standard location installs, which specify executable and                                                                       
   configuration/data locations respectively.                                                                                                 
4  Portage needs a base PREFIX and AFFIX to install to by default.                                                                            
5  Packages need to be updated for support of these feature.                                                                                  
   - Packages that have a standard location of / rather than /usr install into                                                                
     AFFIX rather than PREFIX.                                                                                                                
                                                                                                                                              6  Portage must disallow the creation of binary packages where all                                                                            
   dependencies are not in the same PREFIX.                                                                                                   
7  Portage needs to be able to configured with one-way dependency allowance                                                                   
   between installed package databases. For example, ~ installed packages are                                                                 
   allowed to depend on / installed packages.  
Comment 14 Jason Stubbs (RETIRED) gentoo-dev 2005-05-24 06:55:54 UTC
*** Bug 6474 has been marked as a duplicate of this bug. ***
Comment 15 Jason Stubbs (RETIRED) gentoo-dev 2005-07-28 07:24:37 UTC
Putting a hold on feature requests for portage as they are drowning out the 
bugs. Most of these features should be available in the next major version of 
portage. But for the time being, they are just drowning out the major bugs and 
delaying the next version's progress. 
Any bugs that contain patches and any bugs for etc-update or dispatch-conf can 
be reopened. Sorry, I'm just not good enough with bugzilla. ;) 
Comment 16 Marius Mauch (RETIRED) gentoo-dev 2007-01-11 14:49:26 UTC
Closing due to old age (this is now developed in portage/main/branches/prefix)