As discussed on the -dev mailing list, the way that eix is currently set up requires its tmpfiles entry (tmpfiles.d/eix.conf) to be processed at every reboot. And for that, the user must be running either systemd or OpenRC. If the tmpfiles entry is not processed after /var/cache is cleaned, then eix stops working: $ sudo rm -r /var/cache/eix $ eix-update Reading Portage settings... ... Writing database file /var/cache/eix/portage.eix... cannot open database file /var/cache/eix/portage.eix for writing (mode = 'wb') $ eix portage cannot open database file /var/cache/eix/portage.eix for reading Did you forget to create it with "eix-update"? There are a few other points that I brought up on the mailing list that I'll repeat here for good measure: 1. I don't think it's beneficial for us to treat directories under /var/cache as temporary. We would all be a lot better off if the ebuild could create /var/cache/eix with the correct permissions, and know that it will persist. The FHS doesn't explicitly disallow that, but we should have developer consensus before we do it. 2. Is this data really appropriate for /var/cache/eix if the application can't function without it, and can't recreate it (per the FHS)? If not, moving it to /var/lib/eix addresses the problem. 3. The permissions on the files under /var/cache/eix are not set correctly if I run eix-update for the first time as my mjo user. It's possible that setgid on /var/cache/eix will fix that. 4. A per-user cache would be nice as a fallback, and perhaps addresses the above concerns too. A regular user should be able to maintain and search his own cache of the repo data if he wants to. The location /var/cache/eix could be tried first, so that nothing changes for root (or members of the portage group, if root creates that directory first). tl;dr I would rather *not* see systemd/openrc as runtime dependencies of eix (or any other interactive user application), but so long as the tmpfiles entry needs to be processed, the dependency is implicit, like it or not.
Please don't spam people with bugs based on your mistaken bending on my replies, in order to try to support your wrong thesis. Firstly, eix has eclass-induced RDEP on virtual/tmpfiles, which is sufficient. Secondly, if you purposedly break your system, you shouldn't complain that it magically didn't fix itself.
