Following a kernel upgrade, I ran `module-rebuild rebuild`, which attempted to merge modules in the sequence stated: # module-rebuild rebuild ** Preparing to merge modules: ** Packages which I will emerge are: =sys-fs/zfs-9999 =sys-block/iscsitarget-1.4.20.2_p20120401 =net-misc/r8168-8.028.00 =sys-kernel/spl-9999 sys-fs/zfs depends on sys-kernel/spl, which caused the sys-fs/zfs build to fail.
In some situations, I am finding that modules fail to load at boot because they do not agree on the symbol versions. I assume that is caused by module-rebuild compiling things in the wrong order. I am increasing the importance of this to Major.
sys-kernel/module-rebuild does not do dependency calculations. This causes symbol version issues for ZFS users when sys-kernel/spl and sys-fs/zfs are rebuilt out-of-order. We have `emerge @module-rebuild` in Gentoo stable as of 2.1.11.31, which resolves this issue. A few architectures have yet to stabilize it. When they do, I believe that sys-kernel/module-rebuild should be masked for tree cleaning.
Probably: http://www.gentoo.org/doc/en/kernel-upgrade.xml#doc_chap6 Needs to be changed, I am also unsure about how pkgcore/paludis users will handle this situation is module-rebuild goes away (apart of that, I don't have any problem on treecleaning it, I am also using now portage set ;))
It looks like that version of portage is stable (for stable arches). tree clean?
(In reply to comment #3) > Probably http://www.gentoo.org/doc/en/kernel-upgrade.xml#doc_chap6 needs to be changed Can do that, but I'm not sure if I'm allowed to touch this document. I'll ask around, stay tuned... > I am also unsure about how pkgcore pkgcore appears to be dead, snippet of #pkgcore IRC log on 2013-05-16: > devurandom | Hello! > devurandom | Any recent advances regarding EAPI5 and a new pkgcore release? > Philantrop | devurandom: http://bpaste.net/raw/98158/ <-- IOW: That's it. > devurandom | Philantrop: So it's dead? > Philantrop | devurandom: Yes, that's how I understand what was said here. > @ferringb | heh > @ferringb | Philantrop: that quote isn't quite the whole story; more, I'm just done, doing other things with my time now Quite unfortunate, I'm not sure if someone will pick it up. > paludis users will handle this situation is module-rebuild goes away CC-ed such that they are given at least a heads-up. > (apart of that I don't have any problem on treecleaning it, I am also using now portage set ;)) Is anything holding it back from being treecleaned besides the doc change?
Someone produced a set for Paludis that does the same thing. Dunno if anyone uses it...
Above documentation change has since happened. Is there any other usage case or documentation still blocking this? If not, I think we can start with a package.mask just to be on the safe side and have people report back if there are still such cases.
I use module-rebuild with paludis as part of my kernel upgrade script. I only need to rebuild nvidia-modules and vmeare-modules so not a big loss but it is useful.
I always had trouble with module-rebuild forgetting certain packages, notably x11-drivers/xf86-video-virtualbox, so any improvement is good. emerge @module-rebuild doesn't appear to have that problem. *However* the old module-rebuild has the distinct advantage of rebuilding exactly the same version (unless told otherwise), while "emerge @module-rebuild" updates to the newest version fulfilling all the other dependencies. This sounds like it will cause trouble (at the very least, it throwing warnings "WARNING: One or more updates have been skipped due to a dependency conflict: [...]").
(In reply to ahudson.news from comment #9) > *However* the old module-rebuild has the distinct advantage of rebuilding > exactly the same version (unless told otherwise), while "emerge > @module-rebuild" updates to the newest version fulfilling all the other > dependencies. This sounds like it will cause trouble (at the very least, it > throwing warnings "WARNING: One or more updates have been skipped due to a > dependency conflict: [...]"). Easily fixable by masking versions above needed, ain't it?
(In reply to Nikolaj Sjujskij from comment #10) > Easily fixable by masking versions above needed, ain't it? Well, sort of. But masking/unmasking just for this is painful enough that even in the best case it will lead to: # emerge -pv @module-rebuild # emerge -av1 =module-1 =module-2 [...] being used instead. I guess it is just a question of different expectations, with regard to what "rebuild" means as opposed to "upgrade". It is not like we don't want to upgrade (consciously & safely) at a later point in time, but letting @module-rebuild upgrade the entire VirtualBox dependency hierarchy while there are running instances is actually kind of dangerous. But again, it's not a blocker for removing this dead package; it's just a usability issue with the replacement functionality ;)
(In reply to ahudson.news from comment #11) > It is not like we don't want to upgrade (consciously & safely) at a later > point in time, but letting @module-rebuild upgrade the entire VirtualBox > dependency hierarchy while there are running instances is actually kind of > dangerous. Ah, I see the point (never used VB, really). In that case you can report that issue of @module-rebuild.
