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 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/...
Created attachment 55331 [details, diff] fix two bugs in previous patch to get it work
Created attachment 55550 [details, diff] 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 attachment 56350 [details, diff] 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)
