Summary: | sys-apps/portage-2.2.14 fails to clean outdated versions with sqlite backend | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Sergey S. Starikoff <Ikonta> |
Component: | Unclassified | Assignee: | Martin Väth <martin> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | axs, dev-portage, proxy-maint, xmw |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Sergey S. Starikoff
2015-02-05 11:34:25 UTC
Also, man eix section, describing sqlite cache contains referencies to dead urls: sqlite This is an extremely fast cache method if you are using portage with the sqlite backend, see http://en.gentoo-wiki.com/wiki/Portage_SQLite_Cache (originally this was described in http://gentoo-wiki.com/TIP_speed_up_portage_with_sqlite which might be still accessible at http://gentoo-wiki.info/TIP_speed_up_portage_with_sqlite). Note that in contrast to the default metadata cache method you must use emerge --metadata before you call eix-update with this method. For now backup of this atricle is available at http://gentoo-en.vfose.ru/wiki/Portage_SQLite_Cache What happens if after the "repairing" with another cache method you switch back to sqlite: Are the obsolete versions still gone, or do they re-appear? (In reply to Martin Väth from comment #2) > What happens if after the "repairing" with another cache method you switch > back to sqlite: Are the obsolete versions still gone, or do they re-appear? After switching back to sqlite cache obsolete versions appeared again. I.e.: # grep PORTDIR /etc/eixrc/00-eixrc PORTDIR_CACHE_METHOD='parse' # eix-update … # eix -Ie firefox [I] www-client/firefox Available versions: *10.0.11 24.3.0 24.8.0 31.3.0 ~31.4.0 ~35.0 # vim /etc/eixrc/00-eixrc … # grep PORTDIR /etc/eixrc/00-eixrc PORTDIR_CACHE_METHOD='sqlite' # eix-update … # eix -Ie firefox [I] www-client/firefox Available versions: *10.0.11 17.0.9 24.3.0 24.5.0 24.6.0 24.7.0 24.8.0 ~29.0.1 ~30.0 ~31.0 ~31.1.0 ~31.1.0-r1 ~31.2.0 ~31.2.0-r1 31.3.0 ~31.4.0 ~32.0 ~33.0 ~33.0-r1 ~34.0.5-r1 ~35.0 CC'ing portage team: The test confirms that it is portage's sqlite database which contains the outdated versions. Is it possible to keep in the portage database only the current versions, i.e. to clean up the database in a sense? It appears very artificial (and would take a long time) if eix would need to check that an ebuild actually exists when portage's sqlite database reports it as existent. When you are at it, it would also be nice if /var/cache/edb/dep would receive such a cleaning, since stray data in there might similarly be a problem. Maybe it is possible to introduce a corresponding "emaint" command which eix-sync might call which cleans up the sqlite database and /var/cache/edb/dep? (Such a cleanup might be desirable independent of eix) @Sergey: As a workaround, you can put "-rM" into /etc/eix-sync.conf which causes eix-sync to clean /var/cache/edb/dep and to call emerge --metada to regenerate the sqlite database. This will als solve your bug 538918. Unfortunately, you loose then all of the speed gain of the sqlite backend for eix. (In reply to Martin Väth from comment #4) > CC'ing portage team: > > The test confirms that it is portage's sqlite database which contains the > outdated versions. > > Is it possible to keep in the portage database only the current versions, > i.e. to clean up the database in a sense? > > It appears very artificial (and would take a long time) if eix would need to > check that an ebuild actually exists when portage's sqlite database reports > it as existent. Portage is supposed to delete the outdated versions when you run emerge --metadata or emerge --regen. (In reply to Zac Medico from comment #5) > Portage is supposed to delete the outdated versions when you run emerge > --metadata or emerge --regen. Thanks for the information; I was not aware of this. So - assuming that this really works in portage - I guess the problem is that Sergey is using sqlite cache without emerge --metadata. In this case, eix cannot guarantee that the data is correct: Even if it would check ebuilds for existence, it might happen that not all new ebuilds are contained in the cache. eix would need to do everything portage does and this is too complex for eix. So I close this bug as CANTFIX. @Sergey: Either put -M into eix-sync.conf or FEATURES=metadata-transfer into your portage configuration. For the same reason, I close bug 538918 as CANTFIX. |