Since devfsd and udev now provide virtual/dev-manager we run into a new issue. Specifically, the base profile (in the new cascaded profiles implementation) has virtual/dev-manager as a _required_ package for `emerge system` However, some people prefer to not have a dynamic device manager, and in fact the selinux people need a static /dev tree. So, to make this happen, it's probably better to leave virtual/dev-manager in the base profile, and add a package that creates the static device nodes (separated out of baselayout, I guess). Wacha think, Az, possible to do?
sounds reasonable, want me to create such a package?
that'd be cool greg ... perhaps look at breaking out the makedev stuff from baselayout, put it into static-dev, and then have base-layout DEPEND on virtual/dev-manager ? maybe that might lead to a loop somewhere with devfsd/udev though ...
Wouldnt makedev need to stay with udev systems since udev does not create all of the required stuff yet... (I'm thinking tuntap as an example..)
tuntap works just fine in the latest kernels :)
Ok, in sleeping on this, I don't think this is reasonable to do. A current static dev tree would need over 18000 device nodes (yes, that number is correct.) Do we really want to keep track of all of these? That is why things like devfs and udev were created in the first place. Also, selinux should work just fine with udev, I haven't heard any problems with the users of it in the past. I could create such a huge static dev tree, if people _really_ think it is needed, but as it really hasn't been an issue yet (right?) why go through all of that work for almost no users?
Udev will not work in Gentoo's current setup because of ramfs (no extended attribute support). Also, tar does not save/restore extended attributes.
greg: what about using just `MAKEDEV generic-<arch>` like baselayout does ?
Let's wait on this until after 2004.1 please. Seemant, Az and I talked about this once but didn't conclude yet. Would be good to talk with Greg about it too, but I'm a little exhausted from the recent baselayout work and need a couple days to recooperate... (aka do Real Work)
If you need extended attributes, there's no reason udev can't be using a fs that supports it (it doesn't have to be a ramfs/tmpfs mount.) That's just a configuration issue on the SELinux startup, right? And yes, MAKEDEV is a good tool to create the nodes, but you are wanting a package that actually contains the nodes, correct? Also, I think MAKEDEV is missing a few of the odder device nodes, but no one really notices...
I think the idea is to have an ebuild that once installed would provide a working /dev (like devfs or udev). It could probably just be src_install() { MAKEDEV <blah> } if that works. And it probably doesnt need to contain all of the devices, if people really care about the odd device, they can just create it by hand (like it has always been done with static /dev)...
Yeah, but unmerging such a src_install() wouldn't remove the created nodes, right? Unless 'rm -rf /dev' is an acceptable addition to the uninstall portion of the package :) Anyway, let's wait a bit on this to see if it's really needed.
adding 67276 to the block list, because it's a similar issue
ok, /sbin/rc is updated now so that the user can set $RC_DEVICES in /etc/conf.d/rc to how they want they /dev managed atm we have four settings: auto / udev / devfs / static that takes care of what this bug is about ... as for the issues of ramfs vs tmpfs vs acl's vs tar, those are problems for another day and certainly not this bug look for these fixes in baselayout-1.11.3+
