Bugzilla Bug 269722

eselect with doc USE option fails.
eselect boost set xyzzy fails.

Reproducible: Always

Steps to Reproduce:
1. emerge eselect (with doc option set); or
2. eselect boost set 1.3.0 | eselect boost set 0.3 fail


Actual Results:  
emerge eselect with (doc), fails with:
/usr/bin/rst2html.py < README > README.html
Traceback (most recent call last):
  File "/usr/bin/rst2html.py", line 19, in <module>
    from docutils.core import publish_cmdline, default_description
ImportError: No module named docutils.core
make: *** [README.html] Error 1

eselect boost set xyzzy fails with:
Removing symlinks from old version
!!! Error: ${link}" exists and isn't a symlink
Killed



Expected Results:  
Emerge eselect with doc option should be tested so it works.
Eselect with set option should give a more informative error message, in
particular it should not say "${link}" which provides little information as to
the problem file.

Does python-updater fix your compilation problem? I left a comment on bug
269517 for your second problem.

Running python-updater (which I have done -- it takes 3 hours and produces a
6.6 MB output file) does not fix the problem.

I have determined what part of the problem is.  The developer(s)/testers must
be using a different shell.  Because the eselect script contains instances of
functions of the form "ec_....-xyzzy".  The dash "-" is not a valid character
in symbols in bash.  Changing it to an underscore "_" allows one to get past
that problem.  There is still another problem that I haven't found yet.  I
suspect the "${link}" error message is also due to the use of a different
shell.

Please have the developer(s) use and test shell scripts in "bash-3.2_p39"
rather than whatever they are using.

I am using app-shells/bash-3.2_p39 and it works for me. Have you checked the
suggestions on bug 269517?

Ok, I found out that the "${link}" error is coming from
/usr/share/eselect/modules/boost.eselect.

I modified the file enough to find out that "$link" is /usr/include/boost.  I
suspect that this is yet another bug involving which shell is being used.

It turns out that that was a directory.  If I rename it and do a "eselect set
boost 1" it works!  (yea!).

However the use of an non-standard shell to do development is highly
undesirable.  I note that /usr/bin/eselect starts with "#!/bin/bash".  I also
note that there is an attempt to set "shopt -s extglob" and "shopt -s
expand_aliases".  I am not sure what they do.  I suspect they do not work in
the version of bash I am using or else they may be improper options to get the
behavior that the scripts seem to be written for.

I would suggest that this bug not be labeled as resolved until eselect modules
are released that correct these problems.

https://bugs.gentoo.org/show_bug.cgi?id=269517#c14 strongly applies here. 
Upgrade path was broken for whoever was blindly using $some-overlay, and didn't
know what he was doing.  If you have any of those version installed you have to
uninstall them, clean up /usr/lib{,64} and /usr/include and install boost from
::gentoo.

bash-3.2_p39 has some nasty drawbacks. Did you try bash-3.2_p48, Robert?

Could you please provide us with the following information (and then reopen
this bug):

- output of "emerge --info"
- installed versions of:
    app-admin/eselect
    app-admin/eselect-boost
    dev-python/docutils


(In reply to comment #2)
> Because the eselect script contains instances of functions of the form
> "ec_....-xyzzy".  The dash "-" is not a valid character in symbols in bash.

Hyphens are (and have always been) valid characters in bash function names.
They are forbidden in variable names and in POSIX mode only.

(In reply to comment #4)
> However the use of an non-standard shell to do development is highly
> undesirable.

Sorry, but what are you talking about here?

> I also note that there is an attempt to set "shopt -s extglob" and "shopt -s
> expand_aliases".  I am not sure what they do.  I suspect they do not work in
> the version of bash I am using or else they may be improper options to get
> the behavior that the scripts seem to be written for.

Again, these options exist since a long time (bash-2.05b has both of them).