I'm testing the "pentoo" overlay (https://code.google.com/p/pentoo/source/browse/portage/trunk/profiles/) and switched to its build-in profile (eselect profile list: [15] pentoo:pentoo/hardened/linux/amd64 *) Eix displays all tools as *masked and suggests [D] downgrade with this profile. For example, bash$ eix wireshark [D] net-analyzer/wireshark Available versions: *1.6.8 ~*1.8.0 ~*1.8.0[1] I'm not entirely sure wherever it's the overlay problem or eix. Does eix support custom overlay profiles?
It is always useful to include the version of the tool you are reported the bug against.
I had no time yet to look into the issue, but my first guess is that the profile does not define an "ARCH" variable?
It seems that I was right: echo ARCH=amd64 >$PENTOO_PROFILES/pentoo/hardened/linux/amd64/make.defaults makes the output look right to me. I think that this is a bug in the pentoo profile. Also portage does not recognize that profile here on my system. So unless you can provide a link that the ARCH should be fetched from somewhere else than the profile, I consider this not as a bug of eix. (Therefore marking it as invalid for the time being). As a workaround you can put the make.defaults also in /etc/portage/profile so that it will not be overridden during updates of the pentoo tree.
(In reply to comment #3) > It seems that I was right: > echo ARCH=amd64 >$PENTOO_PROFILES/pentoo/hardened/linux/amd64/make.defaults > makes the output look right to me. yes, that fixed the problem. Thank you! > Also portage does not recognize that profile here on my system. You need the latest stable portage (2.1.10.65) for that, if I'm not wrong. It recognizes it on different setups here without any problem. Thanks again.
Hi, I would like to re-open the bug because the second problem with the downgrade [D] status is still there. I suspect that eix is unable to find profiles/pentoo/common/package.accept_keywords file. bash$ eix wireshark [D] net-analyzer/wireshark 1.6.8 ~1.8.0 ~1.8.0[1] Any suggestions?
After reconsidering the issue, I realized that the problem is actually a different one: The "parents" file content is very strange: gentoo:hardened/linux/amd64 :pentoo/common Accoreding to app-doc/pms, these should be paths relative to the current directory. Obviously, the meaning in the above file is understood as "if the name contains a colon, then it is relative to the "profiles/" directory in the repository specified before the colon". I am not sure what the second line should mean exactly. Perhaps: "if the name starts with a colon, then it is relative to $PORTDIR/profiles"? If both is correct this means that in order to use portage with pentoo, you *must* set PORTDIR to the pentoo path and you *must* include the original gentoo tree into PORTDIR_OVERLAY (so that the repository "gentoo" is recognized). I have extended the logic in the profile parsing in the eix git master branch on BerliOS corresondingly (and BTW, I have also added a DEFAULT_ARCH which defaults to $ARCH during compilation). However, I am not sure whether the above assumptions are correct: After all, I never was able to use portage with the overlay (with various combinations of PORTDIR and PORTDIR_OVERLAY), but at least with the above setting the profile is recognized at all. (I was of course using always latest portage-2.2.0_alpha117 from the very beginning.)
(In reply to comment #6) > After reconsidering the issue, I realized that the problem > is actually a different one: The "parents" file content is very strange: > gentoo:hardened/linux/amd64 > :pentoo/common # indicate that paths such as 'gentoo:targets/desktop' or ':targets/desktop' in # profile parent files can be used to express paths relative to the root # 'profiles' directory of a repository (when the repo name is omitted before # the colon, it refers to the current repository the parent file is inside) from portage(5) I took this to mean that ":" means profiles in the pentoo overlay since that's where the parent file is, and "gentoo:" means the profiles in the gentoo tree. Did I misunderstand something? I read it again and I still feel like I'm going it right (and pentoo is the overlay on my system and everything works fine) > > Accoreding to app-doc/pms, these should be paths relative to the > current directory. Obviously, the meaning in the above file is understood as > "if the name contains a colon, then it is relative to the "profiles/" > directory in the repository specified before the colon". > I am not sure what the second line should mean exactly. Perhaps: > "if the name starts with a colon, then it is relative to $PORTDIR/profiles"? > > If both is correct this means that in order to use portage with > pentoo, you *must* set PORTDIR to the pentoo path and you *must* > include the original gentoo tree into PORTDIR_OVERLAY (so that > the repository "gentoo" is recognized). > > I have extended the logic in the profile parsing in the eix git master branch > on BerliOS corresondingly (and BTW, I have also added a DEFAULT_ARCH which > defaults to $ARCH during compilation). > > However, I am not sure whether the above assumptions are correct: > After all, I never was able to use portage with the overlay > (with various combinations of PORTDIR and PORTDIR_OVERLAY), > but at least with the above setting the profile is recognized at all. > (I was of course using always latest portage-2.2.0_alpha117 from the > very beginning.)
Given the current title of the bug would this be better if I just set EAPI back to 2 like all the other profiles? I mean, I only set 4 because it was the highest supported, I don't believe I actually use anything which *requires* it.
(In reply to comment #7) > from portage(5) So this can only be used if the special pofile-format = portage-2 is used. I was not aware of this portage-only extension. Using it means that the profile is incompatible with other package managers. I consider this extension a very bad idea, especially the treatment of ":..." since the repository need not be uniquely determined by the location of one "random" parent file (which is actually all that is known from the /etc/portage/make.profile link); in fact, the profile need not even belong to any repository at all. Probably it is cleaner (and actually equivalent) if this bad idea is avoided and instead "pentoo:" or "../../../" is used. Anyway, I will try to implement this dirty hack in eix as well. > Given the current title of the bug would this be better if I just set > EAPI back to 2 like all the other profiles? I mean, I only set 4 The EAPI of the pentoo profile is 2, not 4. Maybe you speak about the EAPI of ebuilds? AFAIK, this is supposed to be completely independent of the EAPI of profiles.
I looked up the portage code, and indeed this uses the heuristics that the longest repository path matching the beginning of the path of the "parents" file is considered as the "correct" respository. (The comments in that code suggest that also the portage developers consider this heuristics as hackish.) This also explains why I could not get the profile working with portage: One must add the pentoo profile to PORTDIR_OVERLAY, otherwise the profile is not recognized, because the parents cannot be followed; if the pentoo overlay would use the alternative parent specification I described in the previous comment, users would not run into this problem. I have now implemented the same hackish heuristics into eix, so I suppose that this bug can finally be closed when >=eix-0.26.1 hits the tree. Feel free to test (e.g. with the eix live ebuild from the mv overlay).
> Probably it is cleaner (and actually equivalent) if this bad idea is avoided > and instead "pentoo:" or "../../../" is used. So if I change my current ":pentoo" to "pentoo:pentoo" it would make eix happy and help avoid dirty hacks? If that makes things better for users of alternative package managers I really don't see the issue myself... Please confirm and I'll make the change.
(In reply to comment #11) > So if I change my current ":pentoo" to "pentoo:pentoo" it would make eix > happy <eix-0.26.1 does not understand "repo:path" at all - since you need "gentoo:..." there is no way to make it work correctly with these versions. For >=eix-0.26.1 the interpretation should be the same as of portage. > and help avoid dirty hacks? Experience shows that a feature which is included once included in portage will not be removed. So, unfortunately, it is probably too late to change this (IMHO) misfeature in portage. > I really don't see the issue myself... The problem is that portage (and eix) have only the information "/etc/portage/make.profile points to [some directory]" They do not have the information "this [some directory] is a subdirectory of the repository 'pentoo'" This has to be guessed by some heuristics which has certain problems (e.g. if 'pentoo' resides in /usr/portage/local/ then [some directory] is simultaneously a subdirectory of the repository 'gentoo', but nevertheless 'pentoo' should be chosen; moreover, if symbolic links are involved, one can always construct cases in which this heuristics goes wrong. Finally, the user might want to move [some directory] outside of any repository which is then not possible at all.) You can avoid the heuristics by specifying "pentoo:pentoo", because then no guess is necessary. However, it is even better to specify instead "../../../pentoo" (with the correct number of "../" - I didn't count), because then the profile can be used even if portage does not know the repository "pentoo" (portage does only know the repository "pentoo" if the user included the overlay in PORTDIR_OVERLAY). Hence, using ":pentoo" and "pentoo:pentoo" both have the problem that the profile can only be used if the make.profile link *and* PORTDIR_OVERLAY are modified simultaneously by the user (and ":pentoo" might additionally cause subtle problems...).
> <eix-0.26.1 does not understand "repo:path" at all - > since you need "gentoo:..." there is no way to make it work correctly > with these versions. > For >=eix-0.26.1 the interpretation should be the same as of portage. good to know, I'll force that for my users ;-) > You can avoid the heuristics by specifying "pentoo:pentoo", because > then no guess is necessary. However, it is even better to specify instead > "../../../pentoo" (with the correct number of "../" - I didn't count), > because then the profile can be used even if portage does not know > the repository "pentoo" (portage does only know the repository "pentoo" > if the user included the overlay in PORTDIR_OVERLAY). > Hence, using ":pentoo" and "pentoo:pentoo" both have the problem that the > profile can only be used if the make.profile link *and* PORTDIR_OVERLAY > are modified simultaneously by the user (and ":pentoo" might > additionally cause subtle problems...). of course if PORDIR_OVERLAY is moved the whole idea of ../../../ is completely insane because unless we want to drop support of profiles from inheriting parents across repos we cannot ever really know where the user is putting their local copy of the overlay. pentoo:pentoo makes the most sense, and imho anyone using ../../ to inherit from one repo to another repo should have to type it with bamboo shoots under their finger nails so they learn the pain they are causing others. I will update to pentoo:pentoo and force >=eix-0.26.1 for my users. I hope this solution works for all concerned. As the bug is not assigned to me or reported by me I won't close it, but I believe the above action will resolve the issue. Thanks for your help.
+*eix-0.26.1 (24 Jul 2012) + + 24 Jul 2012; Jeremy Olexa <darkside@gentoo.org> -eix-0.26.0.ebuild, + -files/eix-0.26.0-tools.patch, +eix-0.26.1.ebuild, metadata.xml: + Version bump from upstream for bug fixes (closes Gentoo bugs 425512, 426256, + 427644)
I have just emerged eix-0.26.1, looks good so far. Thanks ;-)
