View previous topic :: View next topic |
Author |
Message |
brendlefly62 Tux's lil' helper
Joined: 19 Dec 2009 Posts: 133
|
Posted: Sat Feb 23, 2013 7:17 pm Post subject: [Solved] module-init-tools and kmod blocking each other |
|
|
Recently built a Raspberry Pi system, and after initial setup, ran emerge -uavDN world -- got two blocks because module-init-tools and kmod are blocking each other. Note that both are part of the system profile and result in warning to that effect if you unmerge them -- I got bold and unmerged module-init-tools anyway. Checked the ebuilds, and confirmed that kmod has
Code: | RDEPEND="!sys-apps/module-init-tools ...
|
and module-init-tools has
Code: | RDEPEND= ...
!sys-apps/kmod |
Please advise... do I need both? if not, which should I have? (why are both in the system profile if they are not both needed?) or basically, what do I do now?
Thanks.
Last edited by brendlefly62 on Sat Mar 23, 2013 11:56 am; edited 1 time in total |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54220 Location: 56N 3W
|
Posted: Sat Feb 23, 2013 7:28 pm Post subject: |
|
|
brendlefly62,
You only need one. kmod is preferred as it can load compressed modules, which is a feature you probably don't need.
From memory, knod goes with a udev update but don't quote me on that. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
brendlefly62 Tux's lil' helper
Joined: 19 Dec 2009 Posts: 133
|
Posted: Sat Feb 23, 2013 8:39 pm Post subject: |
|
|
Thanks, NedddySeagoon,
Since I already unmerged module-init-tools, I won't do any more work to try to get it back.
Is it also safe to get rid of modutils (both virtual/ and sys-apps/modutils) once I have kmod?
I emerged gentoolkit and ran a few equeries, and I found these results.
* These packages depend on kmod:
sys-fs/udev-197-r8 (kmod ? >=sys-apps/kmod-12)
virtual/modutils-0 (sys-apps/kmod[tools])
* These packages depend on module-init-tools:
virtual/modutils-0 (>=sys-apps/module-init-tools-3.2)
* These packages depend on modutils:
virtual/modutils-0 (sys-apps/modutils)
* These packages depend on virtual/modutils:
{nothing}
Note that both the kmod-12-r1 and the module-init-tools-3.16-r2 ebuilds both have
RDEPEND=" ...
!sys-apps/modutils
Am I reading this wrong, or is it inconsistent?
i.e. virtual/modutils depends on kmod, module-init-tools, and sys-apps/modutils, but both kmod and module-init-tools both prohibit sys-apps/modutils ...
Is it safe to get rid of virtual/modutils? (that would appear to be where the blockage I referred to came from -- I believe this started when my "emerge -uavDN world pulled in the current module-init-tools (which blocks sys-apps/modutils and kmod) as well as udev-197-r8 upgrade (which pulled in kmod which blocks sys-apps/modutils and module-init-tools) |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54220 Location: 56N 3W
|
Posted: Sat Feb 23, 2013 8:55 pm Post subject: |
|
|
brendlefly62,
Keep the virtual.
It says Code: | RDEPEND="|| ( sys-apps/kmod[tools] >=sys-apps/module-init-tools-3.2 sys-apps/modutils )" |
Which means its satisfied by either sys-apps/kmod with USE=tools or by >=sys-apps/module-init-tools-3.2 or by sys-apps/modutils
You should not be cleaning your system by hand, except to resolve hard blocks
Run Code: | emerge --depclean -p | to see packages that portage thinks you don't need.
Pay attention to the list before you run it without the -p option.
Careless use will give you a fright as it an remove your active gcc and leave you with a newer but not yet activated version.
It can remove your kernels from /usr/src but it will leave the .config files behind. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
brendlefly62 Tux's lil' helper
Joined: 19 Dec 2009 Posts: 133
|
Posted: Sat Feb 23, 2013 10:27 pm Post subject: |
|
|
aahh , OK - now I understand.
Thank you very much.
This was a good lesson on how to clear blockers -- as a practical method, clearing the blockers required a bit of research into both:
check the ebuilds of both packages,
use equery to learn what depends on them,
check the ebuilds of those packages depending on the blocking packages,
understand virtuals -- and the options they present,
make an informed choice about which option to employ,
only then feel safe using "emerge --unmerge" to clear the blocker. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|