Especially meaning the 9999 ebuilds that are in portage. These ebuilds emerge applications from the development trunk tree.

Here is an example of such an development/trunk/HEAD/9999 (you name it) ebuild:

user@host ~ % eix -I mbpfan
[I] app-laptop/mbpfan
         Available versions:  (~)1.9.1^t (~)2.0.0^t (~)2.0.1^t (**)9999^t{tbz2}
         Installed versions:  9999^t{tbz2}(12:36:41 09/05/18)
         Homepage:            https://github.com/dgraziotin/mbpfan
         Description:         A simple daemon to control fan speed on all Macbook/Macbook Pros

Usually there are only a few such ebuilds on a productive gentoo system and it can time consuming finding ebuilds have been keyworded, if not using the right tools. Using gentoo's portage emerge command, with the right option, it is easy:

user@host ~ % emerge -a @live-rebuild
These are the packages that would be merged, in order:

Calculating dependencies                     ... done!
[ebuild   R   *] app-vim/airline-themes-9999
[ebuild   R   *] www-client/otter-9999
[ebuild   R   *] x11-themes/qtcurve-9999
[ebuild   R   *] media-gfx/pinta-9999
[ebuild   R   *] app-laptop/mbpfan-9999

Would you like to merge these packages? [Yes/No]

This command would at first step search all installed and keyworded ebuilds on the local gentoo system, and emerge then no matter if the development tree has been updated or not.

The upper command does its job very good, but what if one would like update only if trunk has been updated. For this to work one would first need a portage tool. Emerge smart-live-rebuild:

root@host # emerge app-portage/smart-live-rebuild

After app-portage/smart-live-rebuild has been emerged use following command which is a additional option to the emerge. The resulting command is only slightly different to the previous one:

root@host # emerge -a @smart-live-rebuild

These are the packages that would be merged, in order:

Calculating dependencies                         d*** Forking to drop superuser privileges ...
*** Updating the repositories using 6 parallel jobs...
->  https://github.com/dgraziotin/mbpfan.git [HEAD]
--> git ls-remote https://github.com/dgraziotin/mbpfan.git HEAD
->  https://anongit.kde.org/qtcurve [HEAD]
--> git ls-remote https://anongit.kde.org/qtcurve HEAD
->  https://github.com/vim-airline/vim-airline-themes.git [HEAD]
--> git ls-remote https://github.com/vim-airline/vim-airline-themes.git HEAD
->  https://github.com/OtterBrowser/otter-browser [HEAD]
--> git ls-remote https://github.com/OtterBrowser/otter-browser HEAD
->  https://github.com/PintaProject/Pinta.git [master]
--> git ls-remote https://github.com/PintaProject/Pinta.git master
->  [x11-themes/qtcurve:0] https://anongit.kde.org/qtcurve [HEAD]
--> at rev 9aae21bb68308d9017977a53059dd75b347d7bbd (no changes)
->  [app-laptop/mbpfan:0] https://github.com/dgraziotin/mbpfan.git [HEAD]
--> at rev 237eae73e8151e6c24210e027aecf7c461ff0338 (no changes)
->  [www-client/otter:0] https://github.com/OtterBrowser/otter-browser [HEAD]
--> at rev 28fa2bfcf110ec90e54fdcecdef2e0098f30f4a8 (no changes)
->  [app-vim/airline-themes:0] https://github.com/vim-airline/vim-airline-themes.git [HEAD]
--> at rev 4a9595d91eab89f919907b38ef9ae19344029a93 (no changes)
->  [media-gfx/pinta:0] https://github.com/PintaProject/Pinta.git [master]
--> at rev c6ac090832db72db74bf6b301f57952f8a70ecdf (no changes)
*** No updates found (in 5 live packages)                                        ... done!

Nothing to merge; quitting.

The resulting command, searches installed and keyworded ebuilds, compares the development tree - HEAD with local HEAD, then finally builds a list of ebuilds where trunk has been updated. This results in fewer ressources and energy spent to and smarter update routine.

Comparing and summarizing both emerge options live-rebuild will emerge trunk code unconditionally while smart-live-rebuild only rebuilds trunk that has been updated upstream by the upstream developers. The latter will need an previous installation since it is not installed by default.

The main reason why 9999 ebuild are of particular interest, is simple. After updating the gentoo portage tree, these particular ebuild, are never updated by the regular update routine. Like for example using:

root@host # emerge -vauDN system

root@host # emerge -vauDN world

One has to update such ebuilds manually by using the emerge command with the ebuild name.

Thanks to the #gentoo IRC channel OP wraeth who has pointed me to this particular emerge option.

Changing default shells on linux systems from bash to ksh or zsh or even fish is a good idea. I have written a blog post on how to change standard login shell on a system.

If it is done other ways, which might work correctly, it might break your system on a very subtle level and you will not even notice what is wrong. I had a system that was building all packages without problem an issue existed while installing certain ebuilds. The first ebuild that failed installation was x11-libs/libpciaccess this was the first error:

make[2]: Leaving directory '/var/tmp/portage/x11-libs/libpciaccess-0.13.5/work/libpciaccess-0.13.5-abi_x86_64.amd64'
make[1]: Leaving directory '/var/tmp/portage/x11-libs/libpciaccess-0.13.5/work/libpciaccess-0.13.5-abi_x86_64.amd64'
libtool: line 916: print: command not found
libtool: line 4964: print: command not found
libtool: line 5002: print: command not found
libtool: line 2502: print: command not found

It looks as if libtool was broken. But re-emerging x11-libs/libpciaccess did not bring a solution to this particular installation issue. It was not imidiatelly obvious what has been the source of this issue.

Another ebuild had also a installation issue. Before reading the following error message one would need to know zsh has been set as the default login shell for users and for the root. Back to the error message that has been printed while installing app-editors/gvim :

>>> Source compiled.
>>> Test phase [not enabled]: app-editors/gvim-8.0.1298

>>> Install gvim-8.0.1298 into /var/tmp/portage/app-editors/gvim-8.0.1298/image/ category app-editors
make -j2 -C src DESTDIR=/var/tmp/portage/app-editors/gvim-8.0.1298/image/ DATADIR=/usr/share install-icons
make: Entering directory '/var/tmp/portage/app-editors/gvim-8.0.1298/work/vim-8.0.1298/src'
if test -n "/var/tmp/portage/app-editors/gvim-8.0.1298/image/"; then \
        /bin/sh install-sh -c -d /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/icons/hicolor/48x48/apps /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/icons/locolor/32x32/apps \
    /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/icons/locolor/16x16/apps /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/applications; \
fi
if test -d /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/icons/hicolor/48x48/apps -a -w /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/icons/hicolor/48x48/apps \
    -a ! -f /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/icons/hicolor/48x48/apps/gvim.png; then \
   cp ../runtime/vim48x48.png /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/icons/hicolor/48x48/apps/gvim.png; \
   if test -z "/var/tmp/portage/app-editors/gvim-8.0.1298/image/" -a -x "" \
           -a -w /usr/share/icons/hicolor \
           -a -f /usr/share/icons/hicolor/index.theme; then \
         -q /usr/share/icons/hicolor; \
   fi \
fi
zsh:9: parse error near `fi'
make: *** [Makefile:2621: install-icons] Error 1
make: Leaving directory '/var/tmp/portage/app-editors/gvim-8.0.1298/work/vim-8.0.1298/src'

Finally a error message that gives slight hints and specifically this particular line:

    zsh:9: parse error near `fi'

The troublemaker is then zsh. Users and roots login shell has been then switched back to the default /bin/bash.

chsh -s /bin/bash

Now everything should be all right. After building the affected ebuild this issue still persisted. Even if the login shell has been revered to its default value, here a installation issue that hit app-text/ghostscript-gpl :

mkdir -p /var/tmp/portage/app-text/ghostscript-gpl-9.21/image//usr/share/ghostscript/9.21/Resource
/bin/sh -c 'for dir in `ls ./lib/../Resource | grep -v CVS` ; do \
  rdir=/var/tmp/portage/app-text/ghostscript-gpl-9.21/image//usr/share/ghostscript/9.21/Resource/$dir ; \
  test -d $rdir || mkdir -p $rdir ; \
  for file in ./lib/../Resource/$dir/*; do \
    if test -f $file; then ./base/instcopy -c -m 644 $file $rdir ; fi \
  done \
done'
zsh:6: parse error near `done'
make: *** [base/unixinst.mak:125: install-resdata0] Error 1

So what has been done wrong that portage still used zsh as shell? Did portage use zsh still as shell? To find the cause of this error the help of the IRC channel was needed and the helpful people in #gentoo on freenode. The source of this issue was a symlink that has been made in the /bin directory to point to zsh :

user@host $ ls -l /bin/sh
lrwxrwxrwx 1 root root       3  2. Mai 18:59 sh -> zsh

On gentoo systems, possibly on other distributions as well, this particular symlink should point to /bin/bash, like in here:

lrwxrwxrwx 1 root root 4 Jan  4 03:18 /bin/sh -> bash

Now the error messages have not given obvious hints and it took me some time to find this out. Additionally it was not my own system that has affected. It is important if one wants to change the login shell, to set it the right way. Since if it done the clumsy way, even if it is working, it might give a error when one has forgotten about it and the clues will not point down directly to the source of a problem.