Portage-prefix

From Gentoo Linux Wiki

This article is still a Stub. You can help Gentoo-Wiki by expanding it.

The instructions on this page have not kept pace with development and are obsolete. If you are interested in testing the current prototype/work-in-progress, please see Gentoo Prefixed Portage, and Gentoo Prefixed Portage Techdocs in particular.

1 About
2 Requirements
3 Installation
4 Tech Notes
5 TODO
6 Bootstrap Ideas
7 Links
- 7.1 Related Links

[edit] About

This is an effort to allow portage to function as a secondary package manager on Linux, OS X, BSD, and Solaris systems. The current additional features are non-root/non-priveleged portage instances, prefixed package installation, and a wider array of non-Gentoo host system support.

DISCLAIMER: This is a prototype/work-in-progress! Its merely a proof of concept and should not be considered stable or an indication of things to come ;)

[edit] Requirements

At a bare minimum you will need at least:

bzip2
GNU diffutils
GNU make
GNU patch
GNU sed
GNU tar
/bin/sh
an XCU compatible id(1)
curl or wget
>=Python-2.2 (2.4.2 reccomended)

OS X Systems require >=10.4.5 and Xcode >=2.1

[edit] Installation

Grab the latest portage-prefix snapshot and unpack it to the directory of your choice.

$ mkdir -p ~/portage-prefix/tmp ;cd ~/portage-prefix/tmp
$ curl -O http://gentoo.osuosl.org/experimental/snapshots/portage-alt-prefix-latest.tar.bz2
$ tar xvfj portage-alt-prefix-* && cd portage-alt-prefix-*

The important options to be passed to configure are:

--with-user="username" - This is the user that portage itself will run as. It will default to 'portage'
--with-group="group" - This is the group that portage will belong to. It will default to 'portage'
--with-rootuser="username" - This is the user that will own the files portage installs. It will default to 'root'
--with-wheelgid=0 - This is the group id that installed files will belong to. It will default to '0'
--with-offset-prefix=/ - Specifies the installation prefix for all packages. Defaults to "/"
--prefix=/usr - Specifies the installation prefix for portage itself. Defaults to "/usr"
--sysconfdir=/etc - Where portage will look for configuration files(make.conf and so on). Defaults to "/etc"

So to configure portage to use the current user & group, with a final destination dir of /home/kito/gentoo, we would do:

$ ./configure --with-user=`whoami` --with-group=`id -gn` \
--with-rootuser=`whoami` --with-wheelgid=`id -g` \
--with-offset-prefix=/home/kito/gentoo \
--prefix=/home/kito/gentoo/usr --sysconfdir=/home/kito/gentoo/etc

NOTE: On some solaris systems you will need to tell configure the path to an XCU compatible id(1). On solaris10/opensolaris this in /usr/sfw/bin so add this to the configure args:

XCU_ID=/usr/sfw/bin/id

Then to build and install:

$ make && make install

TODO

make.conf editing, DEFAULT_PATH explanation

[edit] Tech Notes

Here are some tips for 'porting' ebuilds to be prefix compliant.

The experimental prefix ebuild repository uses the 'prefix' eapi(ebuild API) to mask ebuilds that are not prefix aware. So, the first thing you'll need to do is tell portage the EAPI near the top of the ebuild after the cvs header, but before any eclass inherits.

# $Header: /var/cvsroot/gentoo-x86/app-arch/tar/tar-1.15.1.ebuild,v 1.17 2005/08/12 08:39:38 flameeyes Exp $

EAPI="prefix"

Most ebuilds that use econf, and the do* utilities will 'just work', but if you do need to manually pass locations to configure, use the ${EPREFIX} variable.

--enable-etcdir=${EPREFIX}/etc/zsh \
--enable-zshenv=${EPREFIX}/etc/zsh/zshenv \
--enable-zlogin=${EPREFIX}/etc/zsh/zlogin \
--enable-zlogout=${EPREFIX}/etc/zsh/zlogout \
--enable-zprofile=${EPREFIX}/etc/zsh/zprofile

The ${ROOT} and ${D} variables in ebuilds will handle ${EPREFIX} transparently. The most frequent change you will need to make is ebuilds that use the DESTDIR=${D} make install target. As ${D} has ${EPREFIX} already appended, this will result in it being appended twice in the final install image. So instead we use the ${EDEST} variable for most make install targets.

Change:

make DESTDIR=${D} install

To:

make DESTDIR=${EDEST} install

[edit] TODO

make sure bin/expr is available after the bootstrap for coreutils
emerge-webrsync for daily snapshots on the mirrors
Handle packages with suid files for non-priveleged instances
Better repoman svn suppport
Bootstrap script ASSIGNED - exg
Scripts to keep svn prefix repo in sync and import 'upstream' ebuild CVS tree (and possibly vice versa for future)...Put this in repoman? got eapify, ecleankw and eupdate - grobian
set shebangs in src_unpack and pkg_postinst
Additional make.conf/envvar options for Applications, Frameworks,sbindir,usrlib,ubindir, etc. etc.
Darwin - how can we support arbitrary destinations for binary packages? There has to be a way to alter the install_names and symlinks for drag and drop install targets
make KEYWORDS in svn repo accurately describe the arches we've actually tested on(!) MOSTLY DONE (esanitise) - grobian
make prefix repo repoman full happy.
make strict default_path optional ASSIGNED - kito
FEATURES="frameworks"
initscript -> launchd translation
use ${PREFIX}/etc/{passwd,group} to propagate external(netinfo) user db / add more netinfo options to enewuser/enewgroup
Add profiles for linux,solaris, opensolaris, and the bsd's
Use xar for binary packages - allow us to retain EAs, Resource Forks, BSD flags, etc.
Fix portage such that relative symlinks can be used for make.profile, currently only absolute symlinks work (bootstrap now tries to setup a correct symlink)
Bootstrap into a temporary directory, instead of in the prefix itself:

 * bootstrapping uses minimal tools, not built as portage would do
 * bootstrap's stuff causes collision protect errors when updating them
 * portage doesn't know about stuf compiled during bootstrap
 * see section on Bootstrap Ideas

[edit] Bootstrap Ideas

Bootstrapping is done using a bootstrap script in ${PORTDIR}/scripts/bootstrap-prefix.sh. This script currently (tries to) build the necessary components to get started with a prefixed portage install. A few problems that become apparent after running the script:

no make.profile is set, and setting it can be tricky (see above) FIXED - grobian: bootstrap now guesses for a profile
the tree assumes you run unstable keywords, the profiles don't FIXED - grobian: bootstrap now sets up make.conf with unstable keywords
portage can't find many essential tools, such as rm, basename, etc. ASSIGNED - kito: --with-default-path configure flag
portage bails out on collision-protect when it tries to install things the bootstrap script installed in the prefix. (solution: don't let the bootstrap script install in the prefix)

It looks like it is a Good Idea(tm) to let the bootstrap script install its stuff in a temporary directory, then add that directory and those of the host OS's toolchain to the --with-default-path configure of the temporary portage install. After that let portage build its whole system in its prefix.

why does the bootstrap have to build gcc, python, etc. if the host OS has sufficient support for those? (i.e. perhaps conditional build?)
bootstrapping + `emerge system` results in building some large packages (e.g. gcc) twice, which is a pity. perhaps we can just use the host OS's gcc, or build in a well known location (e.g. /var/tmp/our-prefix) that, if not to the user's liking, can be symlinked to, to have a binary distribution for the bootstrap stuff, such that the user can immediately start building his system in the prefix location of his choice.

Going this route, a few questions remain:

do we want to get rid of the DEFAULT_PATH that includes some host OS stuff? if yes, portage updates itself too early, and would kill itself by removing the "foreign entries" from DEFAULT_PATH.
if we want to keep DEFAULT_PATH, then why do we build system at all? better make a dynamic package.provided profile then
using "foreign" packages has advantages only as long as you know that they are sufficient (and equal to the way Gentoo would build them). When this is not the case, you better have your own versions. This is the rationale to first try and get rid of dependencies on the host OS, lateron in the process try to build the portage2rpm/apt-get/pkgmng whatever tool for package.provided stuff.