module-init-tools (m-i-t) is being replaced with a library and set of tools provided by kmod. The libraries are still young, but soon to be used by udev, at first as an option. Actually udev git there is a branch using it. See: http://www.jonmasters.org/blog/2011/12/20/libkmod-replaces-module-init-tools/ http://blog.gustavobarbieri.com.br/2011/12/21/kmod-announcement-and-how-to-help-testing-it/ Reproducible: Always
Created attachment 296805 [details] sys-libs/kmod-9999.ebuild
Created attachment 296807 [details] sys-libs/kmod-2.ebuild
Created attachment 296809 [details] metadata.xml
Please consider adding the live (9999) version as well, kmod is changing fast and new releases are expected soon. (Likely it will need a hard mask, as you wish).
CC base-system if is interested.
By the way, I'm one of the authors of the package. The goal is to have the code to fit distribution's needs, then if you need patches to the tools, let me know and I can see how to integrate it upstream. Whenever you need something to help generate initramfs modules list or similar, just say as well. Anyway we should provide python bindings, so people can easily write queries/lookups on their own.
I'll take it.
/var/cvsroot/gentoo-x86/sys-apps/kmod/kmod-2.ebuild,v <-- kmod-2.ebuild initial revision: 1.1 and -9999 in ::mgorny.
Do you think it's better to have it as a sys-APPS instead of LIBS? The main purpose of this project was the library, but anyway would be good, as it's meant to replace module-init-tools apps.
(In reply to comment #9) > Do you think it's better to have it as a sys-APPS instead of LIBS? > > The main purpose of this project was the library, but anyway would be good, as > it's meant to replace module-init-tools apps. Well, udev rquires the apps as well, and we install them by default, so I made it match module-init-tools.
Mgorny, I propose that udev-bugs maintain this, since it is used primarily by udev. I didn't see the bug until a few minutes before this comment; otherwise I would have grabbed it. :-) Also, on gentoo, we will always install to the rootfs, so that shouldn't be a use flag. Let me know what youthink.
(In reply to comment #11) > Mgorny, > > I propose that udev-bugs maintain this, since it is used primarily by udev. Feel free to co-maintain. > Also, on gentoo, we will always install to the rootfs, so that shouldn't be a > use flag. I think that shouldn't be forced, esp. that it needs some hacking as you can notice in the ebuild.
Udev will be force installed into the rootfs; I currently see no reason to change this. Since udev is going to be in the rootfs, this needs to be there also. I see no use case in gentoo for installing these tools into /usr. What is the use case in gentoo for doing this?
Given systemd's explanation about / x /usr, I see no maintainers willing to support this split anymore. Actually udev's maintainer is also systemd maintainer and works at RH as well, they're removing every software from / (/lib, /bin, /sbin...) and this will be unsupported soon. Similarly "sbin" is no more, everything is installed into "bin". Then while this seems like more effort now, I see you having to maintain lots of patched software in future if you want to keep going this way.
(In reply to comment #13) > Udev will be force installed into the rootfs; I currently see no reason to > change this. Since udev is going to be in the rootfs, this needs to be there > also. I see no use case in gentoo for installing these tools into /usr. > > What is the use case in gentoo for doing this? The use case is slowly getting rid of all that junk on rootfs and moving it to /usr as autotools is designed to install. I'd like to experiment a little with udev as well soon but I guess it'd hit hard packages installing rules into random locations.
that is a distro-wide issue to be decided and not something to be added on a per-package basis. thus USE=rootfs-install makes no sense. since this is replacing module-init-tools, i've added the package to the base-system herd. we might want to add a USE flag so people can install this to replace m-i-t rather than being installed alongside it ... considering modprobe/rmmod/insmod require root access, be nice if the configure/makefile respected --sbindir ... but since it seems to be RH driven, i guess that's a pipe dream request. i've added kmod-9999 which merges the live/release worlds into a single ebuild. this way it can be copied to kmod-3 (when it gets released) without requiring modifications. you can also see my proposed changes in there (i've left kmod-2 alone for now).
not directly related, but the out-of-tree building by autotools-utils is obnoxious :p
(In reply to comment #16) > i've added kmod-9999 which merges the live/release worlds into a single ebuild. > this way it can be copied to kmod-3 (when it gets released) without requiring > modifications. you can also see my proposed changes in there (i've left kmod-2 > alone for now). Not that I assume you can't read comments but #8 states exactly where -9999 lives (and is less hacky than yours).
i could care less about random overlays (no idea where to find "::mgorny"). there's no reason at all to not have 9999 ebuilds live in the main tree.
(In reply to comment #17) > not directly related, but the out-of-tree building by autotools-utils is > obnoxious :p I am looking into the live ebuild; I am going to attempt to rework it so we don't need autotools-utils at all; I don't see what this eclass gives us. (In reply to comment #19) > i could care less about random overlays (no idea where to find "::mgorny"). > there's no reason at all to not have 9999 ebuilds live in the main tree. I agree. The live ebuild we will officially maintain is the one in the main tree.
(In reply to comment #20) the only thing autotools-utils gets us is automatic USE=static-libs handling. i'm more inclined to have the ebuild do it itself ... (In reply to comment #18) as for the current "hacky" live ebuild, you'd have to provide actual details to see what you mean. the simple merging of live/non-live ebuilds (i.e. $PV keying) is not a hack.
(In reply to comment #21) > (In reply to comment #18) > > as for the current "hacky" live ebuild, you'd have to provide actual details to > see what you mean. the simple merging of live/non-live ebuilds (i.e. $PV > keying) is not a hack. Like shitting all the release ebuilds with all live details.
well, i'm afraid you're wrong there. so if that's your only complaint, then i guess we can move on. also, drop the coarse language. it has no business here.
@vapier: I have updated the live ebuild with the following changes: - Remove the usage of autotools-utils from the live ebuild since we can do the static libs handling in the ebuild. - Pass --bindir=/sbin to the configure script for now to install the binaries in /sbin. - call portage's default src_install function in src_install. Let me know how you feel about the changes. If the ebuild works for you, I will sync this back to kmod-2.ebuild and close the bug.
Hi Gustavo, (In reply to comment #14) > Given systemd's explanation about / x /usr, I see no maintainers willing to > support this split anymore. > > Actually udev's maintainer is also systemd maintainer and works at RH as well, > they're removing every software from / (/lib, /bin, /sbin...) and this will be > unsupported soon. Similarly "sbin" is no more, everything is installed into > "bin". I understand this, but this is, as vapier said above, an issue that must be coordinated through the entire distro and not by individual packages. For now, we have to install this way until we figure out a method of transition that works for our users. I assure you that it will be addressed. :-) > Then while this seems like more effort now, I see you having to maintain lots > of patched software in future if you want to keep going this way. Actually we aren't patching software at this point, just using the configure options to affect where things are installed.
(In reply to comment #24) we want the non-supervisor binaries in /bin. whether you default to /bin and then move selectively to /sbin or vice-versa doesn't matter. but putting them all in /bin or all in /sbin doesn't work.
@vapier: pursuant to the discussion on -dev, I want to re-work the kmod ebuilds to install in the upstream default location. Everything will go in /usr/bin. This is safe, because it doesn't interfeer with module-init-tools. It doesn't need to be hard masked, because nothing is using it.
kmod-3 is in the tree. This version and kmod-9999 install in /usr.
