Latest changes in eix and eix-remote behaviour (using separate eix-remote database + eix -R for remote search) still have problems with duplicating locally-installed overlays, if they exists in remote database. So, my suggestion is: 1) (optionally) revert -R behaviour back (use single database) and single search pattern 2) (mandatory) use something like attached script to sync remote database (which remove locally-installed overlays from "remote" database). Script called "eur" (Eix Update-Remote), if any. Reproducible: Always
Created attachment 346954 [details] Eix Update-Remote
(In reply to comment #0) > Latest changes in eix and eix-remote behaviour (using separate eix-remote > database + eix -R for remote search) still have problems with duplicating > locally-installed overlays, if they exists in remote database. It's not a bug, it's a feature: From layman -h: [...] corresponding local layman overlay paths are excluded from the update of the current database to avoid confusion. [...] If you do not want this feature [...] use here some path not containing any overlays. Or did you mean the opposite, i.e. is the feature not working for you? In this case set LOCAL_LAYMAN to the path of your layman "storage" directory. It is indeed a bug in current eix that autodetection of that path was broken with current layman-2.0.0 (although there is a fallback heuristic which should work if you use the standard paths). The latter bug should be fixed in eix git master on BerliOS (>=eix-0.28.5). A remark to your code (although I think that the above should solve your problems so that it is not necessary at all): Instead of deleting files, one could use EXCLUDE_OVERLAY or (even better since it avoids troubles with special symbols) the -x argument of eix-update or just not add the corresponding file in eix-remote. Anyway, eix-remote was carefully written to *not* make assumptions based on the filenames because this is unreliable. Moreover, there is not guarantee that repository names obtained remotely are necessarily unique.
Thinking it over, I guess that more people are confused by the feature. Moreover, it seems that you want in your code to exclude the remote data instead of the local layman data. Maybe some other people want that, too. So, in current eix master branch, I added the eix-remote options -x and -X: Without these options, no "duplicate" overlays are omitted, with -x the local overlays are omitted which have remote copies, and with -X instead the remote duplicates are omitted which have local copies. I guess what you want is the option -X.
(In reply to comment #3) > I guess what you want is the option -X. Yes, it is almost perfectly for me now. Thank you very much. Next step to be an ideal — have ability to search in both "remote.eix" and "remote.eix" caches together at the same time. i.e. something like: > eix -someflag pkg > [N] cat-cat/pkg > Available versions: 1 2[1] 3[2] > ... > [1] "foo" /var/lib/layman/foo > [2] "moo" layman/moo (so, search altogether in the tree + in local overlays + in remote overlays)
(In reply to comment #4) > Next step to be an ideal — have ability to search in both "remote.eix" and > "remote.eix" caches together at the same time. eix can search only one database, and it is not reasonable to change this: Otherwise eix would lose its speed and would need an almost complete rewrite. What you want can be done be generating two databases: One containing all information (i.e. with eix-remote with neither option -x or -X) and another built with -X or -x - you can simply write a wrapper around eix-remote if you want to generate that. Then you can use a simple wrapper for eix (or make use of eix -R/-Z) to access one database or the other. I see no sense to provide such wrappers or extensions in eix itself, since it is a rather special requirement: For most people either only -x or -X or neither is enough and they need not change this dynamically.
Closing since eix-0.28.5 is now in the tree
