Summary: | =app-portage/eix-0.29.3 reads profile/package.mask in overlays while portage does not | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Samuel Bauer <samuel.bauer> |
Component: | Current packages | Assignee: | Martin Väth <martin> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arfrever.fta, axs, proxy-maint, xmw |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Samuel Bauer
2013-09-04 00:08:04 UTC
re-launching eix-update fixed it. I thought it had already been done through eix-sync (launched after eix update) Sorry for opening this bug Sorry, again for comment #1, even after eix-update this wrong behavior still appears. Maybe it was a bit late yesterday when I invalided this bug. The issue is discussed in http://forums.gentoo.org/viewtopic-p-7389450.html Summarizing: The science overlay has a profile/package.mask file which masks the stable in-tree versions. eix honours profile/package.mask of all overlays. In contrast, portage (and according to pms portage is right), honours only those ackage.mask files which explicitly are contained in some profile listed throught the "parents" mechanism. Unfortunately, according to pms/portage, overlay maintainers have no way of masking any package which IMHO is very bad. So it *might* be a good idea to keep the current eix behaviour so that users see that someone *wants* to mask the package. On this other hand, the information is then inconsistent with portage, I plan to include a variable ADD_OVERLAY_PROFILES to >=eix-0.23.4 which if "false" uses pms-compliant behaviour while if "true" uses current behaviour. Any suggestions what the default value of this variable should be? (Clearly, pms-compliance is crucial, but OTOH if the default is "false" practically no user will realize the mask suggestions of the overlay-maintainers - certainly the masks are there for a reason.) Perhaps this is something which should be changed in pms/portage? As, said in the first comment, I use UPGRADE_TO_HIGHEST_SLOT="false" Here also is an issue with eix: $ eix -e dev-java/antlr [U] dev-java/antlr Available versions: (0) 2.7.7 ~2.7.7-r1 2.7.7-r2 ~2.7.7-r3 ~2.7.7-r4 ~2.7.7-r5 (3) 3.1.3-r3 {+cxx debug doc examples gunit +java mono python script source static-libs ELIBC="FreeBSD" PYTHON_SINGLE_TARGET="python2_5 python2_6 python2_7" PYTHON_TARGETS="python2_5 python2_6 python2_7"} Installed versions: 2.7.7-r2(00:10:25 10/14/12)(cxx java -debug -doc -examples -mono -python -script -source -static-libs ELIBC="-FreeBSD") 3.1.3-r2(3)(23:06:28 10/13/12)(-gunit -source ELIBC="-FreeBSD") Homepage: http://www.antlr.org/ Description: A parser generator for C++, C#, Java, and Python suggesting me to upgrade dev-java/antlr (in this case nothing is masked in overlays). this package is the only false positive to upgrade when I use eix -uc For other multislot packages, no problems $ eix -e automake [I] sys-devel/automake Available versions: (1.4) 1.4_p6-r1 (1.5) 1.5-r1 (1.6) 1.6.3-r1 (1.7) 1.7.9-r2 (1.8) 1.8.5-r4 (1.9) 1.9.6-r3 (1.10) 1.10.3 (1.11) 1.11.6 (1.12) 1.12.6 (1.13) ~1.13.1 ~1.13.2 ~1.13.3 1.13.4 (1.14) ~1.14 (9999) **9999 Installed versions: 1.9.6-r3(1.9)(02:55:17 10/14/12) 1.11.6(1.11)(02:56:08 10/14/12) 1.12.6(1.12)(16:30:02 04/16/13) Homepage: http://www.gnu.org/software/automake/ Description: Used to generate Makefile.in from Makefile.am In reply to #comment3 thanks for your explanations, i'll keep in mind ADD_OVERLAY_PROFILE for next release. By the way, I would be afraid if any overlay can mask packages. Lot of aren't up to date. Copying the content of package.mask from "trusted" overlay list to portage configuration isn't so difficult. (In reply to Martin Väth from comment #3) > portage (and according to pms portage is right), honours only > those package.mask files which explicitly are contained in some profile > listed throught the "parents" mechanism. Portage supports package.mask (and some other files) in profile-specific locations (/etc/portage/make.profile and parent profiles) and repository-specific locations (${repository_path}/profiles). Repository-specific package.mask in repository A affects ebuilds in repository A and ebuilds in repositories, which specify repository A as master repository (masters attribute in ${repository_path}/metadata/layout.conf). > Unfortunately, according to pms/portage, overlay maintainers have no way of > masking any package which IMHO is very bad. If EAPI of repository (${repository_path}/profiles/eapi) is set to "5-progress", then entries with "::${some_repository}" are supported in repository-specific package.mask in this repository, and these entries allow to mask ebuilds in an unrelated repository. (In reply to Arfrever Frehtes Taifersar Arahesis from comment #6) > "5-progress", then entries with "::${some_repository}" are supported in > repository-specific package.mask in this repository Thanks. Then perhaps the science overlay missed to set this EAPI. (I did not check but considered it as given that portage ignored the mask as described in http://forums.gentoo.org/viewtopic-p-7389450.html) When I consider this situation, I think that the current behavior of eix concerning $OVERLAY/profile/package.mask is appropriate and either I will remove support for ADD_OVERLAY_PROFILE again or I let it default to "true": It is unlikely that somebody uses "::..." without appropriate EAPI. (In reply to Samuel BAUER from comment #4) > $ eix -e dev-java/antlr This is unlreted and seems to be correct behaviour of eix: You have installed version 3.1.3-r2:3, and the current stable veresion in this slot is higher, namely 3.1.3-r3:3, so eix reports correctly. In reply to #comment8 Yes this was unrelated, and no buggy behavior, the only wrong behavior comes from me, I didn't checked which version were installed (antlr:3). Sorry, and thanks for the reply From comment #1 > Wich means: "downgrade to higher version, from stable to instable" I understood why blas-reference::gentoo was masked. But I still do not understand why eix marks this as a downgrade. There is no version which could emerged which is higher or equal to the currently installed version. If you put blas-reference into your /etc/portage/package.accept_keywords, then blas-reference-20120925[1] could be emerged; since this is higher than your currently installed version you would see [U]. Since it seems that reading profile/package.mask in overlays is in accordance with current portage, I mark this bug as fixed. |