You are not logged in.
Pages: 1
(Just a random thought after building a custom kernel from an outdated PKGBUILD)
Building kmod --with-rootprefix=/usr is a Bad Idea™
It breaks the package irreversibly.
With rootprefix=/, one still can run depmod -b /usr . Even without -b, depmod/modprobe built with rootprefix=/ will work on any Arch system as long as /lib is a symlink to /usr/lib.
But rootprefix=/usr can't be undone. depmod will prepend /usr whether or not you ask it to.
I understand it's mostly to force /usr/lib as the only lib.
But why do so if /lib remains a symlink?
Or if /lib is going to be removed completely, why it's not the other way around? (/lib without /usr/lib as some people do)
Offline
Why not just update the PKGBUILD instead?
edit: and the symlink might not stick around forever.
Last edited by Mr.Elendig (2012-08-16 17:49:40)
Evil #archlinux@libera.chat channel op and general support dude.
. files on github, Screenshots, Random pics and the rest
Offline
But why do so if /lib remains a symlink?
Because the loader/linker in executables is hard coded as /lib/ld-linux, so this path must exist. Also this ensures compatibility with foreign binary packages without source code.
Or if /lib is going to be removed completely, why it's not the other way around? (/lib without /usr/lib as some people do)
Because the /usr-Merge was startet this way by other distributions. Also, now /usr will contain the linux system, /etc the configuration, /home the user data, ...
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
https://mailman.archlinux.org/pipermail … 22625.html
For why /usr over /:
https://mailman.archlinux.org/pipermail … 22629.html
Last edited by ZekeSulastin (2012-08-16 19:16:47)
Offline
Oh my. Ok, I see, so the idea was to patch it to support both, but people decided to move on without doing that.
And yep, /boot/modules/VER, or /kernel/VER, or /kernel/modules/VER (in that order) makes more sense to me than /usr/lib/modules.
Ok, thanks, I was unaware of the maillist discussion.
progandy: if /lib remains a symlink (for compatibility etc.) it's ok to have kmod built with rootprefix=/ , there's no need to change it to /usr, that's what I meant.
Mr. Elendig: it's not about PKGBUILDs. It's about crippling the package.
Think of fixing a system with /usr on a separate partition and modules in /usr/lib/modules.
Last edited by axs (2012-08-16 23:43:31)
Offline
Think of fixing a system with /usr on a separate partition and modules in /usr/lib/modules.
How does building kmod with prefix=/ help in that case? /lib is still on usr....
And the /lib symlink will stay around forever.
Offline
How does building kmod with prefix=/ help in that case? /lib is still on usr....
depmod -b /mnt/mounted-usr-partition 3.4.3-ARCH-1
I know there are (ugly) workarounds, but the points stays: with rootprefix=/usr kmod loses flexibility.
Last edited by axs (2012-08-17 07:11:06)
Offline
This seems like a bad bug. kmod should be able to work with any directory. The problem existed before: depmod would only work on /lib/modules/$VERSION/, and now it only works on /usr/lib/modules/$VERSION/. I would expect an option to give it ANY module folder to load.
Offline
Yeah, that option is (kind of) broken by design, and it's exagerrated by the fact Arch people decided to use it.
I think a good approach here would be to supply a full path to -b, i.e. depmod -b /usr/lib/modules, or depmod -b /lib/modules, with ROOTPREFIX acting as an overrideable default value. But current -b semantics is already in kernel makefiles, so it's not that easy to change.
I checked the code and tweaked it a bit, here's the patch: http://pastebin.ca/raw/2194143
The idea was to have modules in ${rootprefix:-}/${modulesdir:-/lib/modules}/$kversion, and use -b $modulesdir -m $rootprefix to override them.
Among other thing, it would allow placing modules in /boot/$kversion or something like that.
I don't like it yet, internally there's absolutely no reason to have two different variables ($rootprefix and $modulesdir) for the path.
Offline
Pages: 1