When doing an "emerge --update --deep --verbose --reinstall changed-use --with-bdeps y world --pretend" I get the following circular dependency: [nomerge ] virtual/modutils-0 [ebuild N ] sys-apps/kmod-12-r1 USE="tools zlib -debug -doc -lzma -static-libs" 0 kB [ebuild N ] virtual/modutils-0 0 kB Total: 2 packages (2 new), Size of downloads: 0 kB * Error: circular dependencies: (virtual/modutils-0::gentoo, ebuild scheduled for merge) depends on (sys-apps/kmod-12-r1::gentoo, ebuild scheduled for merge) (runtime) (virtual/modutils-0::gentoo, ebuild scheduled for merge) (buildtime) This can be temporararly solved using "USE=-tools emerge...." -- Dan Johansson
verified. worked this around by 'emerge --nodeps kmod' instead of temporarily disabling USE="tools" myself. looks like a portage bug?
ok, figured this out: kmod-*.ebuild needs linux-mod.eclass for update_depmod() command for migration from module-init-tools (depmod needs to be ran after first install of kmod) linux-mod.eclass has a RDEPEND for virtual/modutils virtual/modutils has a RDEPEND for kmod[tools] any suggestions that won't break the update from m-i-t to kmod?
this is the fix that introduced the circular: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/kmod/kmod-12-r1.ebuild?r1=1.14&r2=1.15
(In reply to comment #3) > this is the fix that introduced the circular: > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/kmod/kmod- > 12-r1.ebuild?r1=1.14&r2=1.15 Reverted this temporarily: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-apps/kmod/kmod-12-r1.ebuild?r1=1.15&r2=1.16 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-apps/kmod/kmod-9999.ebuild?r1=1.49&r2=1.50 But this means everyone who migrate from m-i-t to kmod won't be able to load modules, and other problems like listing modules with lsmod, etc. due to old files generated by m-i-t in /lib/modules/`uname -r` Forking linux-mod.eclass just to do the dependency comes into mind, but there must be better solution
OK, got it. Modified the eclass to skip the dependency for kmod: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/linux-mod.eclass?r1=1.109&r2=1.110
yeah, let's not do that. ebuilds need to control that behavior, not a hardcoded list of $PN in the eclass.
I think it would also make sense to remove the dependency on virtual/linux-sources for sys-apps/kmod. AFAIK, you don't need kernel sources to build it.
(In reply to comment #6) > yeah, let's not do that. ebuilds need to control that behavior, not a > hardcoded list of $PN in the eclass. This is one time migration path. m-i-t files to be regenerated by kmod, we don't need more universal solution for one time migration. Or do you have a reason why would we need one? I refused one just because of the one-time.
(In reply to comment #8) > (In reply to comment #6) > > yeah, let's not do that. ebuilds need to control that behavior, not a > > hardcoded list of $PN in the eclass. > > This is one time migration path. m-i-t files to be regenerated by kmod, we > don't need more universal solution for one time migration. > Or do you have a reason why would we need one? I refused one just because of > the one-time. As in, this is not the normal use of linux-mod.eclass, and even the update_depmod() function is marked as "internal function" Extending linux-mod.eclass for this one time case which will be moot eventually is overdoing it. What do you propose instead? Moving update_depmod() to linux-info.eclass, perhaps?
(In reply to comment #8) we have a virtual/modutils also, while unlikely, you can have another PN==kmod in a different category and it'd be disabled when it shouldn't have
(In reply to comment #10) > (In reply to comment #8) > > we have a virtual/modutils I'm not following, m-i-t is masked for removal and sys-apps/modutils can only be used for Linux 2.4 which means the files we need to regenerate wouldn't be generated with sys-apps/modutils The only way the files could be generated other than by kmod, is m-i-t, which is now covered > > also, while unlikely, you can have another PN==kmod in a different category > and it'd be disabled when it shouldn't have very unlikely I really don't see any reason for a change or more specific check :/
(In reply to comment #11) trying to justify the code based on current virtual providers doesn't work. the code is logically wrong. it is the ebuild itself that concerns itself with fulfilling the virtual, not the eclass. so it makes sense for the ebuild to be in control of "hey, i'm virtual/modutils, so don't dep on that". then again, the whole use of linux-info is suspect. if users disable module support in their kernel, then obviously module programs won't work. if users are surprised by this, then they're !@#*A morons. i'd drop the code and be done.
> then again, the whole use of linux-info is suspect. if users disable module > support in their kernel, then obviously module programs won't work. if > users are surprised by this, then they're !@#*A morons. i'd drop the code > and be done. ++
(In reply to comment #12) > then again, the whole use of linux-info is suspect. if users disable module > support in their kernel, then obviously module programs won't work. if > users are surprised by this, then they're !@#*A morons. i'd drop the code > and be done. if you enable module loading support in kernel, but don't enable module unloading support, things like `lsmod` will show errors like '-3' in place of showing the module dependencies it is not clear leaving out module unloading will cause module listing to be broken that's why it's there otherwise i would agree, but because of how lsmod interacts with kernels without module unloading capababilities, i don't
(In reply to comment #12) > (In reply to comment #11) > trying to justify the code based on current virtual providers doesn't work. > the code is logically wrong. it is the ebuild itself that concerns itself > with fulfilling the virtual, not the eclass. so it makes sense for the > ebuild to be in control of "hey, i'm virtual/modutils, so don't dep on that". sure ok, i'll change that, give me like half an hour...
Should be fixed in tree now in a way suggested, although there is no reallife difference at this time: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/linux-mod.eclass?r1=1.111&r2=1.112 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-apps/kmod/kmod-12-r1.ebuild?r1=1.17&r2=1.18
(In reply to comment #14) i'm guessing you mean -2 and not -3. this is because lsmod looks at: /sys/module/$MODULE/holders/ /sys/module/$MODULE/refcnt when you have module unloading disabled, the kernel doesn't bother maintaining refcnts/dependency info (why should it? it's not like you can unload anything). that means holders/ is empty and refcnt doesn't exist. the -2 you see is actually the "refcnt" value -- kmod's api returns a negative value when reading the refcnt file fails. as for dependency info, there isn't any, so it isn't displayed. to compare, if you have module unloading enabled, you'll see: Module Size Used by ext2 59424 0 serial_core 20962 1 8250_core but if you have it disabled, you'll see: ext2 59424 -2 serial_core 20962 -2 that -2 is the refcnt (akin to the 0 or 1). so why do we have this dependency in the first place ? to work around a bug in `lsmod` display ? why don't we fix lsmod so that it shows a message or something ?
(In reply to SpanKY from comment #17) > so why do we have this dependency in the first place ? to work around a bug > in `lsmod` display ? why don't we fix lsmod so that it shows a message or > something ? It was there because `depmod` run is required after the switch from m-i-t to kmod for the running kernel, and update_depmod() to accomplish that is in linux-mod.eclass which pulls in the circular dependency I've dropped linux-{info,mod}.eclass usage from sys-apps/kmod and elsewhere, since this seems to be what you were after for http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-apps/kmod/kmod-13-r1.ebuild?r1=1.14&r2=1.15 + same for rest. http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/linux-mod.eclass?r1=1.112&r2=1.113 Now people will need to run manual depmod -a again after emerge -C m-i-t, emerge -1 kmod. To get /lib/modules/$(uname -r) files upgraded like done in kernel's make modules_install I guess that's fine now, most people have upgraded anyways And as for the CONFIG_{MODULES,MODULE_UNLOAD} checks, those were just informative non-fatal warnings, not 'dependencies' per se I guess it's how you look at CONFIG_ checks, for me they are just suggestive Nobody is forcing you to enable unloading support even with the warning