Bugzilla Bug 87877

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:
1.
2.
3.

Created an attachment (id=55252) [details]
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/...

Created an attachment (id=55331) [details]
fix two bugs in previous patch to get it work

Created an attachment (id=55550) [details]
now able to re-install portage with an ebuild keeping user/group-settings; some
other fixes

  07 Apr 2005; <michael.haubenwallner@salomon.at> Makefile.am, acinclude.m4,
  bin/ebuild, cnf/Makefile.in, configure.in, pym/config.py,
  pym/portage_data.py, src/filter-env/Makefile.am, -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.
  added PORTAGE_USER,PORTAGE_GROUP,PORTAGE_ROOTUSER,PORTAGE_WHEELGROUP to
  environment variables, to upgrade with portage.ebuild keeping these names.

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 :)

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
PREFIX-aware.

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
/usr/local.
*) ...

Created an attachment (id=56350) [details]
collection of previous patches, updated agains current cvs

this patch also contains this:
portage_util.writemsg is imported into pym/portage_dep.py (ferringb knows
about)

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
prefix/etc/profile.

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 ?

Pathspec.

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 

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.

googled out what you mean with "pathspec", last not least found on your "random
gentoo" site.

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

second)
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.

third)
... 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.

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.

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.  

*** Bug 6474 has been marked as a duplicate of this bug. ***

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. ;) 

Closing due to old age (this is now developed in portage/main/branches/prefix)