I just tried to emerge lm-sensors-3.6.0 but it's blocked because I'm running an older OpenRC version. Looking at the commit that I could find for this (https://github.com/gentoo/gentoo/commit/1174a168584c2e5485b35df8e88a5b7e85159baa) and the accompanying bug (https://bugs.gentoo.org/680172) I don't see a reason why a blocker was added. So can this blocker be removed/set back to the OpenRC version used in the older lm-sensors ebuild (which was 0.21.7 which supports loading modules from /etc/modules-load.d)? Reproducible: Always
Blast from the past? $ eshowkw openrc Keywords for sys-apps/openrc: | | u | | a a p s a r | n | | m r i p h m s p l i m | e u s | r | d a m a p c x p 6 3 a p s i | a s l | e | 6 r 6 6 p 6 8 p 8 9 s r h c p | p e o | p | 4 m 4 4 c 4 6 a k 0 h c a v s | i d t | o ----------+-------------------------------+-------+------- 0.41.2 | + + + + + + + + ~ ~ ~ + ~ ~ ~ | 6 # 0 | gentoo [I]0.42.1 | + + + + + + + + ~ ~ ~ + ~ ~ ~ | 7 o | gentoo 9999 | o o o o o o o o o o o o o o o | 7 o | gentoo
Yeah, I'm using an older OpenRC version (from an overlay), so if we're just looking at the gentoo tree it shouldn't be an issue. But the blocker seems wrong to me in any case, I might be missing something though.
What business does that overlay have to fork openrc?
I tend to close this as invalid. You found the correct bug. We got several bug reports from people saying "there is no modules-load service" so depending on an OpenRC version which provides modules-load service make sense from my POV. But please answer question why you have to run such an old OpenRC version but must run latest lm-sensors. This services was added in 2016(!).
(In reply to Thomas Deutschmann from comment #4) > I tend to close this as invalid. You found the correct bug. We got several > bug reports from people saying "there is no modules-load service" so > depending on an OpenRC version which provides modules-load service make > sense from my POV. > > But please answer question why you have to run such an old OpenRC version > but must run latest lm-sensors. This services was added in 2016(!). Hi Thomas, thanks for the response and info. I don't think your assessment is correct because OpenRC 0.21.4 introduced support for /etc/modules-load.d (with a new service called modules-load), see https://github.com/OpenRC/openrc/blob/master/NEWS.md#openrc-021. So if support for /etc/modules-load.d is required the minimal version should be 0.21.4. This I think is the only thing that matters for this issue, the dependency is simply not correct. The stuff below is all extra, not related to the incorrect dependency: Since I was looking at the ebuild and the dependency anyway I noticed another issue and that's that the ebuild for 3.5.0_p20190505.ebuild and 3.6.0 aren't correct in that they contain references to the modules-load service but also depend on OpenRC>=0.36 which removed the modules-load service, see https://github.com/OpenRC/openrc/blob/master/NEWS.md#openrc-036. And finally there is no hard dependency of lm-sensors on OpenRC or a specific OpenRC version, one can run the scrips/binaries without OpenRC, create the config file manually, not use modules, etc so using a hard block seems like the wrong solution. If there are things unclear to the users it was either because the previous message wasn't clear enough or as in the aforementioned bug it contained the wrong information. The solution to this is to make the message to the user better (this could also mean simpler, so remove the detail of which service to use, just inform the user to load his/her kernel modules, that should be enough for gentoo users to make that happen via whatever whichever way they want, gentoo is about choice after all) or alternatively a simple change to the message to reference the correct service name or even mention both service names would've worked as well.
