Upgrading from eix 0.12.4 to either 0.13.1 or 0.13.2 (followed by 'update-eix') wants to downgrade any installed package. For example: [D] app-portage/eix Available versions: (EAPI=prefix) *0.12.4 *0.13.1 *0.13.2 {PDEPEND=} Installed versions: 0.13.2(EAPI=prefix)(18:51:54 07/14/08)(-doc -sqlite) Homepage: LICENSE=GPL-2 Description: IUSE=doc sqlite Reproducible: Always Steps to Reproduce: 1. emerge -v eix 2. update-eix 3. eix eix Actual Results: [D] app-portage/eix Available versions: (EAPI=prefix) *0.12.4 *0.13.1 *0.13.2 {PDEPEND=} Installed versions: 0.13.2(EAPI=prefix)(18:51:54 07/14/08)(-doc -sqlite) Homepage: LICENSE=GPL-2 Description: IUSE=doc sqlite Expected Results: Expected it to report eix as being installed 0.12.4 works fine
@Martin: any idea?
Created attachment 160390 [details, diff] Patch to print the profile directories which eix uses Please try with the attached patch: Are the directories printed the correct (symbolic resp. "true") paths to your profile and its parents?
There appears to be another (independent) problem with your output: All data (e.g. homepage/description/...) seems to be rubbish. Does this problem vanish when you downgrade eix? Which cache method(s) are you using (i.e. what is the output of "(cache: " in update-eix)?
(In reply to comment #3) > There appears to be another (independent) problem with your output: > All data (e.g. homepage/description/...) seems to be rubbish. > Does this problem vanish when you downgrade eix? > Which cache method(s) are you using (i.e. what is the output of "(cache: " > in update-eix)? > As another data point. %% grep CACHE ~/.eixrc PORTDIR_CACHE_METHOD=parse|ebuild* OVERLAY_CACHE_METHOD=parse|ebuild* Looks fine here.
yeah, but froog is on rsync, so he has metadata, and hence has the default cache method...
(In reply to comment #5) > yeah, but froog is on rsync, so he has metadata, and hence has the default > cache method... I suspect that he has actually cache method "flat" or something similar, although he should have either "metadata" or "portage-2.1". Or maybe the content of /usr/portage/metadata/cache/*/* is in a different format? Does e.g. /usr/portage/metadata/cache/app-portage/eix-* contain lines of the form "LICENSE=GPL-2" "IUSE=doc split" or do they just look like "GPL-2" "doc split" (i.e. without "=" sign)? (The latter is expected by "metadata", because this is the case for the x86 portage tree). Anyway, I cannot imagine why this behavior should have changed with eix-0.13. In contrast, eix-0.13 has a different way to resolve links, in particular for cascading profiles, because of bug 229091 - that's why I ask to report the output of the patch.
you can examine our cache yourself here: http://rsync1.prefix.freens.org/metadata/cache/app-portage/eix-0.13.2 Maybe our ebuild does the wrong thing, as I think it doesn't set any default currently, see http://rsync1.prefix.freens.org/app-portage/eix/eix-0.13.2.ebuild
(In reply to comment #7) > as I think it doesn't set any default currently, see > http://rsync1.prefix.freens.org/app-portage/eix/eix-0.13.2.ebuild This is the reason for the different behavior of eix-0.13.* and eix-0.12.4: In the eix-0.12.4 ebuild there was a (different) default cache method chosen. > you can examine our cache yourself here: > > http://rsync1.prefix.freens.org/metadata/cache/app-portage/eix-0.13.2 Indeed, the format differs from that of the "standard" portage tree. I have now introduced in eix svn trunk a new cache method "metadata-assign" which should be able to read this new format. Please test the new trunk with PORTDIR_CACHE_METHOD="metadata-assign". If it works, this method is of course much faster (and more secure) than the previous method "parse|ebuild*": It is then probably a good idea to make it the default format in the next eix ebuild (for this tree) by using ./configure option --with-portdir-cache-method=metadata-assign The change of the default cache method in the eix-0.13.* ebuilds explains all effects in the bug report, i.e. it is probably not necessary to test with the above patch anymore. (Moreover, with current eix svn trunk you can get the effect of the patch simply by putting -DDEBUG_PROFILE_PATHS to CXXFLAGS.)
(In reply to comment #8) > This is the reason for the different behavior of eix-0.13.* and eix-0.12.4: > In the eix-0.12.4 ebuild there was a (different) default cache method chosen. Agreed. > > http://rsync1.prefix.freens.org/metadata/cache/app-portage/eix-0.13.2 > > Indeed, the format differs from that of the "standard" portage tree. > I have now introduced in eix svn trunk a new cache method "metadata-assign" > which should be able to read this new format. Please test the new trunk > with PORTDIR_CACHE_METHOD="metadata-assign". I'm confused. Our cache is generated in the same way as gentoo-x86 cache is generated (at least it uses the same scripts...). The only difference between portage-2.1 and portage-2.2 IIRC is that the latter no longer transforms the metadata/cache into its own /var/cache/whereever (emerge --metadata run after --sync). Portage 2.2 just directly uses the metadata/cache. Most confusement comes from our cache indeed having a different format as gentoo-x86. I need to ask around for that. Portage seems to work fine (fast) with it... > If it works, this method is of course much faster (and more secure) than the > previous method "parse|ebuild*": It is then probably a good idea to make it > the default format in the next eix ebuild (for this tree) by using > ./configure option --with-portdir-cache-method=metadata-assign I guess we have to do that, or figure out how we get compatible cache. Seems we generate incorrectly at the moment. > The change of the default cache method in the eix-0.13.* ebuilds explains > all effects in the bug report, i.e. it is probably not necessary to test > with the above patch anymore. (Moreover, with current eix svn trunk you can > get the effect of the patch simply by putting -DDEBUG_PROFILE_PATHS to > CXXFLAGS.)
(In reply to comment #9) > I'm confused. Our cache is generated in the same way as gentoo-x86 cache is > generated (at least it uses the same scripts...). I have no idea how the gentoo-x86 cache is generated. However, I can tell you some cases when portage is using which format, perhaps it helps: 1. The format which I call "flat" (i.e. without variable assignments) is used (a) in the exported gentoo-x86 cache /usr/portage/metadata (as you know already) (b) With portage-2.0.* in /var/cache/edb (generated by emerge --metadata) (c) With all portage versions, this format is generated by the ebuild.sh script. 2. The "assignment" format which is in your metadata was apparently introduced with portage-2.1; the only place where I know that it is used in "standard" gentoo is in /var/cache/edb. This has also not changed with portage-2.2 (the only difference is that emerge --metadata has to be called explicitly to generate /var/caceh/edb at all). However, I have no idea about what repoman does - maybe a crucial difference can be found there.
It seems that gentoo-x86 uses some backwards compatible format "metadata_gmirror" which I don't use. In that respect, we can consider this bug to be on our side, not eix' side. I'm trying to switch to the right format, but that is of course another python hell story.
just to check: http://rsync1.prefix.freens.org/metadata/cache/app-portage/eix-0.13.2 that is the cache format we're looking for, right? In a minute or 20 this should be on the slaves. Froog can you sync and try again then to see if eix behaves?
(In reply to comment #12) > http://rsync1.prefix.freens.org/metadata/cache/app-portage/eix-0.13.2 Yes, this is what I meant by "flat" format in comment #10. I will leave support for metadata-flat (previously: "metadata") and metadata-assign in >=eix-0.13.3 in any case: If the flat format is already considered as only "backward compatible", it is perhaps just a matter of time until the x86 tree will use metadata-assign. Since to my knowledge no other tools use the metadata information, it is perhaps worth a consideration to use already the more advanced "assign" format in prefix (if you configure eix for the metadata-assign default). But it is of course a political decision which you have to decide.
I'm not against using the assignment format (it looks much cleaner to me) but I understood from the Portage team that it'll break some tools. Of course Prefix has no backwards compatibility issues, so it makes less sense for us. I do not know if it has any performance issues (Portage team says it doesn't make much difference for Portage), but at this point I prefer to be in line with the "future" of gentoo-x86 (given ideally we want to be merged there). Since the cache format is now the same, I consider this bug fixed. Thanks for the input!
