i2c-2.9.0 refers to kernel i2c for 2.6 kernels i2c-2.9.1 was recently added and slotted. So lm_sensors-2.9.0 has i2c as a dep and wants to upgrade it. Because the new i2c is slotted it comes up as new and installs the package when it should not. Reproducible: Always Steps to Reproduce: 1.add kernel i2c 2.emerge lm_sensors 2.9.0 (if this is not already) 3.mask lm_sensors 2.9.1 4 emerge lm_sensors Actual Results: lm calls for the i2c dep. this now wants to install the new slotted i2c pkg. lm_sensors-2.9.1 is valid but the previous lm_sensors-2.9.0 is now broken. The line : DEPEND=">=sys-apps/i2c-${PV} is no longer valid when >= can refer to i2c-2.9.1 lm_sensors-2.9.0 should call for =i2c-2.9.0 I'm not a dev , so I wont guess at what a correct dep would be , I'll just flag the error. Expected Results: I should be able to rebuild the versions I have installed. For some reason I put a mask on lm_sensors-2.9.0 , this used to compile correctly , since i2c-2.9.1 entered the tree, that latter is incorrectly installed as new package. Now I have spent the time to debug it I could mask i2c as well but portage is there to take of such dependacies so the ebuild should be corrected.
The behavior of lm_sensors-2.9.0 and below is broken with respect to 2.6.x kernels. This has been fixed in 2.9.1. You will need to run `emerge -C i2c` before upgrading to lm_sensors-2.9.1. This is not a bug.
>The behavior of lm_sensors-2.9.0 and below is broken Not that broken. At least it compiled OK when I installed it and has been working ever since. Looking at the i2c-2.9.0.ebuild it seems to detect 2.6 kernels and not install the package. That seems to work. Now a version that is installed and working can no longer be rebuilt with the same source and the same ebuilds. That to me is a bug in portage. I dont like this sort of regression , it wastes too much time debugging minor packages. When changes are made they should be thought through. Testing the latest version and ignoring the rest is not sufficient . That is why I submitted a bug report. It worked 6 weeks ago now it fails. It's a bug.
lm 2.9.0 is _now_ broken because of the >=sys-apps/i2c-${PV} . That is why I suggested correcting it. "=sys-apps...." would seem more useful.
A given package can not depend on an exact version of another package unless that package is slotted, which is not the case for i2c. It can not be slotted since two versions can not be installed side-by-side. Why can't you just use lm_sensors-2.9.1 which has all this fixed?
Apparently it is no longer slotted, when I first looked at this a few days back it came up [NS] . The fact that i2c 2.9.0 "does nothing" on a 2.6 system presumably means it could be slotted. If I masked >lm 2.9.0 there was a reason . I will now unmask it or mask i2c to the same level. I have had to spend the time debugging this and have found the cause and the solution. The point of the bug report was to point out that a working ebuild was now disfunctional. If there is really no better solution (unlikely) then it will have to stay broken. Regressions in portage the main weakness in an excellent distro so I try to contribute when I find an issue. IMHO what builds today should build tommorrow unless there is a huge security hole that has necessitated a package being removed. Regressions should be corrected. Best regards.
When you mix ~ARCH with ARCH there are no guarantees it will work as expected.
well it seems a second error was created in bringing one part of 2.9.0 out of testing while i2c remains ~x86. Now it seems that lm2.9.0 has come out of ~x86 but i2c-2.9.0 is still unstable . bash-3.00#etcat -v i2c [ Results for search key : i2c ] [ Candidate applications found : 3 ] Only printing found installed programs. * sys-apps/i2c : [ ] 2.8.7 (0) [ ~ ] 2.9.0 (0) [ ~ ] 2.9.1 (0) bash-3.00#etcat -v lm_sensors [ Results for search key : lm_sensors ] [ Candidate applications found : 3 ] Only printing found installed programs. * sys-apps/lm_sensors : [ ] 2.8.7 (0) [ I] 2.9.0 (2.6.11-nitro2) [M~ ] 2.9.1 (0) So the lm_sensors-2.9.0.ebuild is doubly wrong. DEPEND=">=sys-apps/i2c-${PV} This dependancy will ALWAYS mix stable and unstable _in addition_ to the original bug that is sent where it will emerge i2c package on top of kernel i2c. This has obviously been hacked around without any testing other than emerging 2. 9.1 Now if that situation seems satisfactory to the maintainer of this package and two fatal flaws are deemed to be "invalid", who am I to argue. I am clearly wasting my time posting.
brix@sponge ~/projects/gentoocvs/gentoo-x86/sys-apps/lm_sensors $ grep ^KEYWORDS *.ebuild lm_sensors-2.8.7.ebuild:KEYWORDS="-ppc -sparc x86 amd64" lm_sensors-2.9.0.ebuild:KEYWORDS="~x86 ~amd64 ~ppc" lm_sensors-2.9.1.ebuild:KEYWORDS="~x86 ~amd64 ~ppc" brix@sponge ~/projects/gentoocvs/gentoo-x86/sys-apps/lm_sensors-modules $ grep ^KEYWORDS *.ebuild KEYWORDS="~x86 ~amd64 ~ppc" brix@sponge ~/projects/gentoocvs/gentoo-x86/sys-apps/i2c $ grep ^KEYWORDS *.ebuild i2c-2.8.7.ebuild:KEYWORDS="x86 ppc amd64" i2c-2.9.0.ebuild:KEYWORDS="~x86 ~amd64 ~ppc" i2c-2.9.1.ebuild:KEYWORDS="~x86 ~amd64 ~ppc" As you can see from the above, neither i2c-2.9.0, i2c-2.9.1, lm_sensors-2.9.0 nor lm_sensors-2.9.1 has been marked stable on any ARCH. Most likely you have unmasked packages locally using /etc/portage/package.keywords.
So I have both on ~x86 , what was your previous post refering to: >When you mix ~ARCH with ARCH there are no guarantees it will work as expected.
*** Bug 99638 has been marked as a duplicate of this bug. ***
