vaeth / eix

eix can access Gentoo portage ebuild information and description very quickly (using a local cache). It can also be used to access information on installed packages, local settings, and local and external overlays, and informs about changes in the tree
GNU General Public License v2.0
165 stars 13 forks source link

eix-update with git produces empty database #18

Open hartwork opened 8 years ago

hartwork commented 8 years ago

Hi!

I turned /usr/portage/ from rsync to Git like this:

# cat /etc/portage/repos.conf 
[gentoo]
sync-type = git
sync-uri = https://github.com/gentoo/gentoo.git
auto-sync = yes

# emaint sync --auto
[..]

Now I would expect eix-update to re-build a healthy index but it reports to not find any e-builds (which there are plenty) as I read the output:

# eix-update 
Reading Portage settings...
Building database (/var/cache/eix/portage.eix)...
[0] "gentoo" /usr/portage/ (cache: metadata-md5-or-flat)
     Reading category 163|163 (100) EMPTY!
Applying masks...
Calculating hash tables...
Writing database file /var/cache/eix/portage.eix...
Database contains 0 packages in 163 categories.

Is my setup not supported? Could it be? Are there workarounds that I could try? Many thanks in advance,

Sebastian

vaeth commented 8 years ago

If you use a git repository which does not contain metadata, you must create them locally, using egencache.

hartwork commented 8 years ago

Thanks for the pointer to egencache. I am unsure how to best improve the situation so the the next person will not have to find this ticket or open a duplicate. Any ideas?

vaeth commented 8 years ago

Let's leave the ticket open. It is about the 5th time already I gave a similar answer...

dxli commented 8 years ago

@hartwork

thanks for the tip. I just moved to git repo and got this issue

For the eix-update EMPTY issue, the command which fixed my issue is

egencache --repo=gentoo --update
# eix-update 
Reading Portage settings ..
Building database (/var/cache/eix/portage.eix) ..
[0] 'gentoo' /usr/portage/ (cache: metadata-md5-or-flat)
     Reading category 163|163 (100%) Finished         
Applying masks ..
Calculating hash tables ..
Writing database file /var/cache/eix/portage.eix ..
Database contains 18915 packages in 163 categories.
shiznix commented 8 years ago

So does the egencache command now need to be run every time the git repo is synced?

mercuriete commented 8 years ago

I hit the same issue. Thanks you very much.

drunkard commented 8 years ago

Here's my script /etc/portage/postsync.d/eix-update:

!/bin/bash

if [ -e /etc/portage/make.conf ]; then . /etc/portage/make.conf if [ ! -d $PORTDIR/metadata/md5-cache -o -d $PORTDIR/.git ]; then echo "updating metadata cache ..." egencache --repo=gentoo --update fi fi

/usr/bin/eix-update

But the first egencache --repo=gentoo --update is very very long ...

mercuriete commented 8 years ago

hi guys. for someones that hit this issue...

this repo -> https://github.com/gentoo-mirror/gentoo.git

this is a git repo that actually have metadata.

i will fix the problem with this repos.conf

[DEFAULT] main-repo = gentoo

[gentoo] location = /usr/portage sync-type = git sync-uri = https://github.com/gentoo-mirror/gentoo.git auto-sync = yes

Cheers! :smile:

vaeth commented 8 years ago

One does not really want to keep the history of metadata in a git repository: It's an enormous waste of disk space.

I have now created a set of /etc/portage/repo.postsync.d/* files which take care about downloading the cache and/or calling egencache to generate the metadata (and also download some other data like news and GLSAs which are not provided in the gentoo repository). Details are highly configurable, and some emphasis is put on security.

You can install it as the package app-portage/portage-postsyncd-mv from the mv overlay (available over layman).

lisyarus commented 3 years ago

Hello from 2021, just upgraded to using git for main gentoo overlay & faced the same problem. Maybe there should be at least some warning message somewhere at eix when moving to a git repo?

ajakk commented 1 year ago

Nobody should be using sync-uri = https://github.com/gentoo/gentoo.git. Instead point sync-uri at https://github.com/gentoo-mirror/gentoo, which contains the metadata cache.

konsolebox commented 4 months ago

Nobody should be using sync-uri = https://github.com/gentoo/gentoo.git. Instead point sync-uri at https://github.com/gentoo-mirror/gentoo, which contains the metadata cache.

Unless you are developing against ::gentoo as well. Don't even dare suggest absurd workarounds like creating another worktree or even worse create a duplicate version of repos.conf/gentoo.conf just for this. You test your ebuilds against the actual repo clean, no possibly conflicting duplicates and no unnecessarily confusing stuff.

konsolebox commented 4 months ago

Those using https://github.com/gentoo/gentoo can configure /var/db/repos/gentoo to use a different location for the md5-cache.

Here's an example eixrc configuration that uses https://github.com/gentoo-mirror/gentoo's md5-cache:

CACHE_METHOD="/var/db/repos/gentoo metadata-md5:/var/db/repos/gentoo-mirror/metadata/md5-cache"

One can create a repo.postsync.d script that updates /var/db/repos/gentoo-mirror/metadata/md5-cache every time /var/db/repos/gentoo gets updated. Not all files have to be "checked out".

#!/bin/sh

set -e

if [[ $1 == gentoo ]]; then
    cd /var/db/repos/gentoo-mirror/
    timeout --foreground --kill-after=20 --signal=TERM 60 git fetch origin master
    rm -fr metadata/md5-cache
    git checkout origin/master -- metadata/md5-cache
fi

Note: I don't generally recommend using set -e in scripts besides in simple ones like the brief example above which doesn't even have messages.

Also if it isn't obvious enough, no, you don't create a repos.conf entry for /var/db/repos/gentoo-mirror. Set it up manually.