It seems that current version of epm (1.33) does not support portage related environment variables at all.
Reassigning to maintainer-needed since package was not being maintained by anyone in tools-portage herd.
OK, I found documentation of ROOT in |man make.conf| and I agree that it should be supported in epm. But PORTAGE_CONFIGROOT is not documented there. What does it do? But my main question is: how would I query them? They are not part of the normal environment. Would it be enough to parse /etc/make.conf and /etc/portage/make.conf?
Reassigning to Peter. Peter, I can work with you on figuring out where and how we need to use the various portage variables.
No need to parse: python -c 'from portage import settings ; print settings["ROOT"]' As for PORTAGE_CONFIGROOT: Directory containing the filesystem from which emerge should read Portage configuration files. Often you will want to point this to the same directory as ROOT. Default value is "/". Example: PORTAGE_CONFIGROOT="/usr/powerpc-softfloat-linux-uclibc" http://www.gentoo.org/proj/en/base/embedded/cross-development.xml
Peter, do you still proxy maintain this package?
No, it has been a while that I sent patches to Paul, but I doubt he ever integrated them into his git repo. Currently, I'm not even using Gentoo. So please do with epm whatever you like.
We will treeclean it as agreed with fuzzyray
Isn't this bug report about a feature request? What exactly is the issue that it needs to be removed? I understand that there is no upstream maintainer nor a proxy-maintainer willing to care for it. But why remove it as long as it is still working fine? I'm using `epm` nearly on a daily basis on multiple different systems and it seems to work fine for me.
I agree with Reto. I am new to Gentoo, with a background in RHEL, so I find epm reduces the learning curve, and the frustration level of answering questions about a package. I have not experienced any problems with it, either. Although I am not trying to separate the target and host environments. I might be willing to take a whack at it, but ... - What is this support really buying, other than simple compleatness? What is a likely environment where epm would fail without this support ... and how might one quickly create such a test environment (remembering that I am new to Portage)? - I'm not familiar with contributing to an Open Source project - If I'm able to fix it, can I just send someone a 'diff' patch, or is there more process involved?
(In reply to dmw from comment #9) > - If I'm able to fix it, can I just send someone a 'diff' patch, or is > there more process involved? You can attach a unified diff directly to this bug report, created like this: diff -u /usr/bin/epm.orig /usr/bin/epm
(In reply to Tom Wijsman (TomWij) from comment #4) > http://www.gentoo.org/proj/en/base/embedded/cross-development.xml Hi, Tom (or anyone with some answers :) ), That link is dead. Is the usage of PORTAGE_CONFIGROOT to relocate /etc/portage? or to relocate /var/db ? or to relocate something else? Or to relocate both /etc/portage and /var/db ? When/why would I want to use PORTAGE_CONFIGROOT ? For example, when I am installing Gentoo on a new machine, I boot the Gentoo Live DVD, mount the hard drive on /mnt/gentoo, then eventually (leaving out lots of steps) chroot /mnt/gentoo and emerge whatever. Is PORTAGE_CONFIGROOT supposed to be some kind of alternative to that? Is ROOT supposed to be some kind of alternative to the chroot? Does PORTAGE_CONFIGROOT act as a prefix for paths that it is affecting, or as a total replacement for whatever path or paths it is affecting?
(In reply to Zac Medico from comment #10) > You can attach a unified diff directly to this bug report, created like this: > > diff -u /usr/bin/epm.orig /usr/bin/epm Thanks for the very clear and concise answer, Zac!
(In reply to Svyatoslav Trukhanov from comment #0) > It seems that current version of epm (1.33) does not support portage related > environment variables at all. Hi, Svyatoslav, Can you describe what you were trying to do (and what layout you were trying to use), that did not work for you? Can you suggest a simple testcase for each variable that is important to you?
Hey anybody know any answers to my earlier questions? It would be really nice to fix this, but without some answers, I have no way of knowing whether I've done what is requested, or make broken code that looks pretty. If someone had, or could clearly explain, a setup which correctly used these variables in the main part of Portage, it (hopefully) wouldn't be hard to tell whether epm was reporting on that setup correctly.
The ROOT and PORTAGE_CONFIGROOT variables are both documented in `man emerge`. Basically, portage config files should be read from $PORTAGE_CONFIGROOT/etc/portage, and the installed package database should be read from $ROOT/var/db/pkg.
Thanks, Zac! I'm really glad for the simple answers ... I wasn't sure whether it meant /etc/portage/** or /usr/share/portage/config/** or /var/lib/portage/** for PORTAGE_CONFIGROOT when it said "config files". So PORTAGE_CONFIGROOT is just referring to /etc/portage tree, that helps. I had mistaken "ROOT ... the target root filesystem to be used for merging packages or ebuilds" as the root of the whole system (I thought that to merge a package meant to install its contents where each file belonged). But it's actually the root of the package database only, right? Would EPREFIX adjust where the deployed files actually went? To make a test environment recognizably different from my real Portage setup, without really installing junk, is this going to work: mkdir -p /someplace/root_test/var/db /someplaceelse/p_cr_test/etc cp -a /var/db/pkg /someplace/root_test/var/db/ cp -a /etc/portage /someplaceelse/p_cr_test/etc/ emerge --root /someplace/root_test --config-root /someplaceelse/p_cr_test \ ??????????????????????? an-unusual-package But what to tell emerge so that it doesn't really install the files into root filesystem ?
So is anyone willing to take care of this or are we proceeding with the removal, or...?
(In reply to dmw from comment #16) > I had mistaken "ROOT ... the target root filesystem to be used for merging > packages or ebuilds" as the root of the whole system (I thought that to > merge a package meant to install its contents where each file belonged). > But it's actually the root of the package database only, right? Well, it's really "$ROOT/$EPREFIX", also known as EROOT in ebuilds. > > Would EPREFIX adjust where the deployed files actually went? Yes, the files are installed under "$ROOT/$EPREFIX" aka EROOT. > To make a test environment recognizably different from my real Portage > setup, without really installing junk, is this going to work: > > mkdir -p /someplace/root_test/var/db /someplaceelse/p_cr_test/etc > cp -a /var/db/pkg /someplace/root_test/var/db/ > cp -a /etc/portage /someplaceelse/p_cr_test/etc/ > emerge --root /someplace/root_test --config-root /someplaceelse/p_cr_test \ > ??????????????????????? an-unusual-package > > But what to tell emerge so that it doesn't really install the files into > root filesystem ? Maybe you're looking for the --pretend option? (In reply to Michał Górny from comment #17) > So is anyone willing to take care of this or are we proceeding with the > removal, or...? This particular "enhancement" request is a silly reason to remove the package if there is still demand for it. We've already got comments on this bug from 2 people who seem to be interested in keeping it around. That said, I'm not really interested in maintaining it myself.
(In reply to Zac Medico from comment #18) > (In reply to dmw from comment #16) > > Maybe you're looking for the --pretend option? Hi, Zac, So would --pretend cause all of the database updates to be made? I'm working on trying to set up a throw-away environment for testing, so if I can't get around this, it won't be the end of the world. > (In reply to Michał Górny from comment #17) > > So is anyone willing to take care of this or are we proceeding with the > > removal, or...? > > This particular "enhancement" request is a silly reason to remove the > package if there is still demand for it. We've already got comments on this > bug from 2 people who seem to be interested in keeping it around. > > That said, I'm not really interested in maintaining it myself. I'm going to try it. Still trying to get enough of a system installed to have the environment I need, though ... VirtualBox is next. :) When I get somewhere with it, then epm might be resurrected, so stay tuned!
Well, we agreed with previous maintainer about finally killing this because each time this arises, someone appears supposedly going to update it and keep it alive... but I think this is at least the second time that finally nothing happens and we keep providing the exact same old/unmaintained version :/ Then, until I see any real work going on, I would treeclean this still
Hi, All, That's pretty much as I agreed with Paul Varner: "Demonstrate that something happens", then I can ask to have it resurrected. That's running slower than I would like, because I'm unable to get anything beyond the hypervisor-only Gentoo installed on my machine: VBox bug 588750 is preventing me from installing VBox, so I can't create any Linux environment that I can do any kind of real work in, yet. :S Pacho, Regardless of what happens, let's keep this Bug open as a known way to communicate. Douglas
> Pacho, Regardless of what happens, let's keep this Bug open as a known way > to communicate. Correction, Pacho, Regardless of whether you have to treeclean epm while waiting for me to get it updated, let's keep this Bug open as a known way for everybody to communicate.
(In reply to dmw from comment #21) > That's running slower than I would like, because I'm unable to get anything > beyond the hypervisor-only Gentoo installed on my machine: VBox bug 588750 > is preventing me from installing VBox, so I can't create any Linux > environment that I can do any kind of real work in, yet. :S This should not really be an obstacle to working on epm. All that you really need is any Linux system (could be Fedora or Ubuntu) with root access, where you can unpack a gentoo stage3 tarball and chroot into it. You don't necessarily even need root access, if you use gentoo prefix, but that will have some obstacles of its own. By far, chroot is the easiest way to go: https://wiki.gentoo.org/wiki/Chroot
Thanks, Zac. Looks like this might work: I created a jail directory and restored a backup of the Gentoo hypervisor into it. That means my real Gentoo no longer has to be at risk by serving as the 'control' in experiments. Then created a second jail inside of the first-level jail and restored the Gentoo hypervisor into that, also. Now I can chroot into the first one, experiment with introducing differences into the second one using root, eprefix, etc with emerge, and even if I make a mistake and damage the first jail, the real Gentoo is protected. With differences introduced, that should let me tell which one epm is reading from as I put in the ROOT, etc environment variables ... I think. :)
removed
