rm -rf /var/cache/eix: i.e. for change db to sqlite: eix-0.26.4 : ----------------- rm -rf /var/cache/eix LANG=en eix-update Reading Portage settings .. Building database (/var/cache/eix/portage.eix) .. [0] "gentoo" /usr/portage/ (cache: sqlite) Reading Packages .. Finished [1] "rion" /usr/local/portage/layman/rion (cache: parse#metadata-md5#metadata-flat#assign) Reading category 156|156 (100%) Finished [2] "stuff" /usr/local/portage/layman/stuff (cache: parse#metadata-md5#metadata-flat#assign) Reading category 156|156 (100%) Finished [3] "sunrise" /usr/local/portage/layman/sunrise (cache: parse#metadata-md5#metadata-flat#assign) Reading category 156|156 (100%) Finished Applying masks .. Calculating hash tables .. Writing database file /var/cache/eix/portage.eix .. Can't open the database file '/var/cache/eix/portage.eix' for writing (mode = 'wb') ----------------- 0.23 - just works ----- metod - independent arch - independent ( x86/amd64 ) new USE dep - independent Reproducible: Always
The same problem on version 0.25.5.
Same here.
mkdir /var/cache/eix/ touch /var/cache/eix/portage.eix chown portage:portage /var/cache/eix/portage.eix ----------- dirty hack, because this is eix-update's work
just return class Permissions in the eix-update.cc ( and some deps ) or some analog curent version not works correctly anyway
> rm -rf /var/cache/eix You shouldn't do this. You can _clean_ this directory, but you should not remove it or change its permissions (unless you really need different permissions for some reason). > dirty hack, because this is eix-update's work Quite the opposite: It is not a user program's task to create random directories or files in /var/cache whose creation requires root permissions. _This_ was a horrible hack, necessary only because eix did not have a dedicated directory for which it had write permissions. Finally, this security hole has been closed. I do not plan to reintroduce it. (BTW: class Permissions was meant for a single file, not for a subdirectory setup. Also, portage:portage is correct only for the default user "portage" which is undesired or even nonexistent in several systems. Finally, changing permissions is not possible anyway, because eix-update drops root permissions ASAP; eix-update simply is so complex that it should not run as root.) Security and convenience always go against each other, but if in doubt, I decide for security.
