Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 462926 - linux-mod.eclass: Don't pull in virtual/modutils if the eclass is used from sys-apps/kmod to avoid circular dependency
Summary: linux-mod.eclass: Don't pull in virtual/modutils if the eclass is used from s...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Kernel Miscellaneous
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-24 10:37 UTC by Dan Johansson
Modified: 2013-08-24 11:15 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Johansson 2013-03-24 10:37:29 UTC
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
Comment 1 Samuli Suominen (RETIRED) gentoo-dev 2013-03-24 11:00:42 UTC
verified. 
worked this around by 'emerge --nodeps kmod' instead of temporarily disabling USE="tools" myself.
looks like a portage bug?
Comment 2 Samuli Suominen (RETIRED) gentoo-dev 2013-03-24 11:44:46 UTC
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?
Comment 3 Samuli Suominen (RETIRED) gentoo-dev 2013-03-24 11:46:56 UTC
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
Comment 4 Samuli Suominen (RETIRED) gentoo-dev 2013-03-24 11:51:39 UTC
(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
Comment 5 Samuli Suominen (RETIRED) gentoo-dev 2013-03-24 14:18:59 UTC
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
Comment 6 SpanKY gentoo-dev 2013-03-24 18:54:05 UTC
yeah, let's not do that.  ebuilds need to control that behavior, not a hardcoded list of $PN in the eclass.
Comment 7 Mike Gilbert gentoo-dev 2013-03-24 18:58:33 UTC
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.
Comment 8 Samuli Suominen (RETIRED) gentoo-dev 2013-03-24 19:04:51 UTC
(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.
Comment 9 Samuli Suominen (RETIRED) gentoo-dev 2013-03-24 19:09:20 UTC
(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?
Comment 10 SpanKY gentoo-dev 2013-03-24 21:00:07 UTC
(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
Comment 11 Samuli Suominen (RETIRED) gentoo-dev 2013-03-25 08:14:09 UTC
(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 :/
Comment 12 SpanKY gentoo-dev 2013-03-25 20:31:14 UTC
(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.
Comment 13 Rick Farina (Zero_Chaos) gentoo-dev 2013-03-25 20:33:52 UTC
> 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.

++
Comment 14 Samuli Suominen (RETIRED) gentoo-dev 2013-03-26 07:45:40 UTC
(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
Comment 15 Samuli Suominen (RETIRED) gentoo-dev 2013-03-26 07:55:16 UTC
(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...
Comment 16 Samuli Suominen (RETIRED) gentoo-dev 2013-03-26 08:21:11 UTC
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
Comment 17 SpanKY gentoo-dev 2013-04-27 11:01:50 UTC
(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 ?
Comment 18 Samuli Suominen (RETIRED) gentoo-dev 2013-08-24 11:15:18 UTC
(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