eix doesn't use $EPREFIX/etc/eixrc as its configuration file. Using opensnoop shows (I have EPREFIX=/Volumes/Gentoo): UID PID COMM FD PATH 502 80298 eix 3 /dev/dtracehelper 502 80298 eix 3 /dev/urandom 502 80298 eix -1 /Volumes/Gentoo/Volumes/Gentoo/etc/eixrc 502 80298 eix -1 /Users/embe/.eixrc 502 80298 eix 3 /Volumes/Gentoo/lib/libbz2.1.dylib 502 80298 eix 3 /Volumes/Gentoo/usr/lib/gcc/i686-apple-darwin9/4.0.1/libgcc_s.1.dylib eix doesn't try to read $EPREFIX/etc/eixrc -- it tries $EPREFIX/$EPREFIX/etc/eixrc instead.
I wouldn't be surprised if it's caused by this: - Use environment's EPREFIX to find /etc/eixrc if PORTAGE_CONFIGROOT is unset. Personally, that sounds wrong to me, apart from my doubts on whether PORTAGE_CONFIGROOT has anything to do with eix' configuration. Additionally, I have no clue if EPREFIX is meant to be a Prefix specific thing here, or whether it is some other thing that unfortunately uses a name we frequent a lot in Prefix...
@vaeth: could you tell me if eix' EPREFIX is meant for Prefix, or whether it is something entirely different?
Judging from the code, I think it might work if we would set sysconfdir to /etc explicitly. That would mess up eixrc.in comments, but it looks like the code would go well with that...
(In reply to comment #1) > PORTAGE_CONFIGROOT has anything to do with eix' configuration. Yes, it has. eix tries to imitate portage's behavior. > Additionally, I have no clue if EPREFIX is meant to be a Prefix specific > thing This was the original intention; and from the prefix-portage description it appeared to me that simple EPREFIX had to be prefixed to all paths. It turned out that this was correct only for certain paths - that's why the scheme became finer and more configurable and EPREFIX slightly lost its original meaning: Now the default is such that EPREFIX can also be used for chroot partitions on which standard portage is installed. > I think it might work if we would set sysconfdir to /etc explicitly. So as I understand, prefix-portage sets usually sysconfdir to $EPREFIX/etc? Then this is indeed double (I am surprised that nobody realized this earlier; I had expected that sysconfdir _is_ /etc/ in prefix portage and just merging into the tree appends the EPREFIX). So yes, from the way the code is written, setting sysconfdir to /etc during "make" would be the correct thing (this would have the advantage that EPREFIX could still be used for chroot environments). The only thing one has to try is whether autotools do honour the change of sysconfdir for only the install phase (i.e. whether changing sysconfdir to $EPREFIX/etc during "make install" really causes installation of eixrc into the correct directory).
(In reply to comment #4) > setting sysconfdir to /etc during "make" would be the correct thing I meant of course already for "./configure".
After having slept about it, I have changed my mind: The double meaning EPREFIX has in the moment is not good. In >=eix-0.13.4, I plan to split it in "EPREFIX" and "EIX_PREFIX"; for prefix-portage, one should then just keep sysconfdir=${EPREFIX}/etc everywhere and only use --with-eprefix-default (and not --with-eix-prefix-default) in ./configure, i.e. the current ebuild can be kept.
(In reply to comment #4) > > I think it might work if we would set sysconfdir to /etc explicitly. > > So as I understand, prefix-portage sets usually sysconfdir to $EPREFIX/etc? > Then this is indeed double (I am surprised that nobody realized this earlier; > I had expected that sysconfdir _is_ /etc/ in prefix portage and just merging > into the tree appends the EPREFIX). > So yes, from the way the code is written, setting sysconfdir to /etc > during "make" would be the correct thing (this would have the advantage > that EPREFIX could still be used for chroot environments). > The only thing one has to try is whether autotools do honour the change of > sysconfdir for only the install phase (i.e. whether changing sysconfdir to > $EPREFIX/etc during "make install" really causes installation of eixrc into > the correct directory). This won't work. First, what we want is to have the system configuration to reside in $EPREFIX/etc. That's what we specify, and how autotools works. (It defaults to ${prefix}/etc. We need it for configure/compile (the right value has to be encoded in the Makefiles and other .in files, and the right path needs to end up in the source files). Messing around with different values for it during different phases is ugly and bound to generate trouble. So what I understand is that EPREFIX is not a Prefix thing in eix. From your explanation it sounds like you want ROOT in there. That's what Portage does, in the end. PORTAGE_CONFIGROOT is just for Portage to read configuration from another location, but differently than ROOT. See also my note on this very topic I made in pym/portage/const.py (in Prefix): # We have a most confusing situation here, which is most of all pretty # weak for protecting us from making mistakes. # First there is a config_root (PORTAGE_CONFIGROOT) which can be a path # somewhere, from which all paths need to be relative (e.g. # etc/portage), hence those constants do NOT have EPREFIX, because # config_root contains EPREFIX by default -- overriding it loses the # EPREFIX as one would expect. # Second there is target_root (ROOT) which is to install somewhere # completely else, in Prefix of limited use. Because this is an offset # always given, the EPREFIX should always be applied in it. Those # constants (like VDB_PATH) DO have EPREFIX. # Unfortunately this file is ordered quite horrible in this respect.
I like it when alt stays in the loop. I'd like to encourage you not to use EPREFIX for anything non-Prefix.
(In reply to comment #8) > I like it when alt stays in the loop. > > I'd like to encourage you not to use EPREFIX for anything non-Prefix. ... because Portage does "cross-Prefix" if EPREFIX is set in the environment ... because many users have EPREFIX set in their environment because it's handy
(In reply to comment #8) > I like it when alt stays in the loop. Sorry, I did not expect that your CC is omitted when I take the bug; I just think that - after my decision - it is something which has to be fixed in eix and not in the alt-tree - that's why I hijacked this bug. > I'd like to encourage you not to use EPREFIX for anything non-Prefix. I try to do this, but still it is not easy to define what "Prefix" should mean for eix (since eix in a sense tries to imitate portage...). I hope that the new solution (in current eix svn trunk) is correct also from your point of view. (As mentioned earlier, this is meant to work with the current ebuild, i.e. the only thing different from standard portage is that you should call --with-eprefix-default "${EPREFIX}" in ./configure). Suggestions are welcome, of course. (In reply to comment #8) > From your explanation it sounds like you want ROOT in there. Similar, but not exactly. Portage has a very specific meaning for ROOT, namely where to merge the packages. I think the new name "EIX_PREFIX" is now rather appropriate for the intended meaning. Actually, since I made the same observation ... > # We have a most confusing situation here, which is most of all pretty > # weak for protecting us from making mistakes. ... I had decided to make a different variable for practically every path; so the system should be flexible enough to get the correct behavior for both, EPREFIX and the new EIX_PREFIX, and perhaps some other uses, too, by just choosing the correct default values for the various variables.
eix-0.13.4 fixes this, right?
(In reply to comment #11) > eix-0.13.4 fixes this, right? I hope so; however, since this was the only path which was reported to be wrong, I changed only that EPREFIX is not used for finding eixrc. Any other paths remain as they are...
eix-0.13.4 is in the prefix tree now, please reopen if more problems of this kind occur in that version.
eix-0.13.4 doesn't work. It defines EIX_PREFIX_DEFAULT as "/Volumes/Gentoo". The reason is probably line 312 of configure.in: AC_ARG_WITH(eprefix-default,[ --with-eix-prefix-default=STR default EIX_PREFIX], The first argument should be eix-prefix-default, not eprefix-default.
Thanks for investigating. The stupid copy-and-paste typo is fixed in svn trunk.
Ok, eix-0.13.{3,4} is masked. We can resolve this bug when a new release comes out. Thanks for your time guys.
*** Bug 239109 has been marked as a duplicate of this bug. ***
All, please test 0.14.0, I am also emerging that now. Thank you.
All appears well in my world. -removed masked versions -cleaned up p.mask -resolved this bug. Please re-open or file a new bug if problems persist.
