Summary: | lm_sensors-2.9.0 ebuild now defective. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | genbug |
Component: | New packages | Assignee: | Mobile Herd (OBSOLETE) <mobile+disabled> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | triod |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Other | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
genbug
2005-06-22 08:24:37 UTC
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. *** |