Since Version 1.147 of eclass/kernel-2.eclass (Version from CVS) there is a RDEPEND pointing to virtual/dev-manager. Since I've a static /dev, I've choosen not to merge devfs or udev and this worked for my server like a charm. Now I can't do an "emerge world", 'cause it tries to emerge udev (which I've masked in /etc/portage) I've included a nonsense line in /etc/portage/profile/virtuals (pointing virtual/dev-manager to sys-apps/portage) but this can't be the solution! Commit in CVS was from johnm, if this helps in assigning the bug. Reproducible: Always Steps to Reproduce: Actual Results: ~ # emerge -pv --debug hardened-sources These are the packages that I would merge, in order: Calculating dependencies Parent: None Depstring: sys-kernel/hardened-sources Candidates: ['sys-kernel/hardened-sources'] ebuild: sys-kernel/hardened-sources-2.6.10-r3 binpkg: None - Parent: ebuild / sys-kernel/hardened-sources-2.6.10-r3 merge Depstring: !build? ( sys-apps/sed >=sys-devel/binutils-2.11.90.0.31 ) doc? ( app-text/docbook-sgml-utils app-text/xmlto ) !build? ( >=sys-libs/ncurses-5.2 sys-devel/make ) virtual/dev-manager Candidates: ['sys-fs/udev'] !!! All ebuilds that could satisfy "sys-fs/udev" have been masked. !!! One of the following masked packages is required to complete your request: - sys-fs/udev-059 (masked by: package.mask, ~x86 keyword) - sys-fs/udev-058 (masked by: package.mask) - sys-fs/udev-056 (masked by: package.mask) - sys-fs/udev-045 (masked by: package.mask) - sys-fs/udev-060 (masked by: package.mask, ~x86 keyword) - sys-fs/udev-064-r1 (masked by: package.mask, ~x86 keyword) - sys-fs/udev-062 (masked by: package.mask, ~x86 keyword) - sys-fs/udev-063 (masked by: package.mask, ~x86 keyword) - sys-fs/udev-064 (masked by: package.mask, ~x86 keyword) - sys-fs/udev-065 (masked by: package.mask, ~x86 keyword) - sys-fs/udev-066 (masked by: package.mask, ~x86 keyword) - sys-fs/udev-067 (masked by: package.mask, ~x86 keyword) - sys-fs/udev-068 (masked by: package.mask) - sys-fs/udev-069 (masked by: package.mask, ~x86 keyword) - sys-fs/udev-068-r1 (masked by: package.mask) - sys-fs/udev-070 (masked by: package.mask, ~x86 keyword) - sys-fs/udev-030 (masked by: package.mask) For more information, see MASKED PACKAGES section in the emerge man page or section 2.2 "Software Availability" in the Gentoo Handbook. !!! (dependency required by "sys-kernel/hardened-sources-2.6.10-r3" [ebuild]) This happens with other kernel-sources as well, so this is not specific to my local copy of the older hardened-sources, they are not in portage anymore. The block is because I've masked udev, but thats not the point. The point is the new dependancy in kernel-2.eclass. Portage 2.0.51.22-r2 (default-linux/x86/2004.2/gcc34/2.6, gcc-3.4.3-20050110- hardenednossp, glibc-2.3.4.20040808-r1, 2.6.10-hardened-r3-local i686) ================================================================= System uname: 2.6.10-hardened-r3-local i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.6.13 ccache version 2.3 [enabled] dev-lang/python: 2.3.5-r2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -fstack-protector -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/ config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks loadpolicy notitles sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.gg3.net/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="x86 aalib acpi acpi4linux alsa apache2 apm bash-completion crypt curl eds emboss fortran gd gif gnutls gstreamer gtk2 hardened imagemagick imlib innodb jpeg libg++ libwww mad mikmod mp3 mysql ncurses nls nptl pam perl pic png pnp python readline sdl slang spell sqlite sse ssl svga symlink tcpd tiff userlocales vhosts zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
So put udev into /etc/portage/profile/package.provided; I don't think that static dev is supported at all.
You can switch RC_DEVICES in /etc/conf.d/rc to static, so there _is_ support for that configuration. And in some startups scripts there are refrences for static /dev too. And last but not least the log-entry for the mentioned changes is: "Fixes a bug, which I cant find :) Also helps out those who want static /dev, afterall virtual/dev-manager is correct in base profiles" How does it help? For me this is wrong behaviour. I don't understand the dependancy since kernel does not depend on udev/devfs and for profiles where it is required the entry is in the packages file. Putting udev in package.provided is imho bad since there are packages that use it if it is present.
(In reply to comment #2) > You can switch RC_DEVICES in /etc/conf.d/rc to static, so there _is_ support for > that configuration. And in some startups scripts there are refrences for static > /dev too. And last but not least the log-entry for the mentioned changes is: > "Fixes a bug, which I cant find :) Also helps out those who want static /dev, > afterall virtual/dev-manager is correct in base profiles" > How does it help? For me this is wrong behaviour. > I don't understand the dependancy since kernel does not depend on udev/devfs and > for profiles where it is required the entry is in the packages file. > Putting udev in package.provided is imho bad since there are packages that use > it if it is present. OK.. I wont go into this all to much at first. Basically... It helps out static /dev because for quite some time the eclass has forcably depended on udev for 2.6.13+, this is because devfs was dropped. virtual/dev-manager is in the base profile, and as such is inherited by every profile except for those which specifically mask it. Depending on this virtual means anythign which fulfills the virtual will work. At the moment I udev and devfs still exist in portage (of course), and both these provide dev-manager. This helps a static /dev because the user is able to a: specify that dev-manager is provided by packages.provided, or to handle it however way they like. In the case of the busybox profile it actually uses bash as the virtual. The dependancy is there so that we might enforce a typical behaviour from our kernels. Generally, and definately from 2.6.13+ this defaults to udev. There is an idea of putting in a dummy ebuild for static-dev users which provides dev-manager.
What about a use flag for static /dev? Or maybe a feature? Static /dev is especially for servers a good and widely used thing imho. Haven't looked into it, but I think there is a problem with the vserver-profile too, since there is -*virtual/dev-manager in the packages-file. Btw, putting virtual/dev-manager in package.provided doesn't help, seems there is no support for virtuals in that file. Workaround is putting some dummy-ebuild in virtuals-file. Atm that whole thing is a little bit.. complex. ;)
(In reply to comment #4) > What about a use flag for static /dev? Or maybe a feature? No, you can't inherit eclass conditionally.
(In reply to comment #5) >> What about a use flag for static /dev? Or maybe a feature? > No, you can't inherit eclass conditionally. For the RDEPEND-statement in the eclass, something like that (example only): RDEPEND="!build? ( >=sys-libs/ncurses-5.2 sys-devel/make ) !staticdev? (virtual/dev-manager)"
that isn't really going to be an option. It's a bit needless in all honesty. I think the best solution is to just let you have a dummy ebuild to provide it. Nedd, do you have any comments on this. I know you were working with it.
(In reply to comment #0) > Portage 2.0.51.22-r2 (default-linux/x86/2004.2/gcc34/2.6, gcc-3.4.3-20050110- > hardenednossp, glibc-2.3.4.20040808-r1, 2.6.10-hardened-r3-local i686) > CFLAGS="-march=pentium4 -fstack-protector -O2 -pipe" ^^ Stefan Off topic but your setup is asking for trouble. For the most part using -fstack-protector in CFLAGS can be problematic. ---------------------------------------------------------------------------- (In reply to comment #7) > that isn't really going to be an option. It's a bit needless in all honesty. > I think the best solution is to just let you have a dummy ebuild to provide it. > > Nedd, do you have any comments on this. I know you were working with it. What was wrong with virtial/dev-manager and blocking !devfs if >=2.6.13 as we discussed? !staticdev?() <-- I know I don't really care for yet another new USE flag to handle this. An 'emerge static-dev' that can PROVIDE=virtual/dev-manager ; that just runs ( cd /dev/ ; sh ./MAKEDEV generic ) seems like it would be an ok. We probably just have to be sure portage does not remove device nods on pkg removal/upgrades.
(In reply to comment #8) > (In reply to comment #7) > > that isn't really going to be an option. It's a bit needless in all honesty. > > I think the best solution is to just let you have a dummy ebuild to provide it. > > > > Nedd, do you have any comments on this. I know you were working with it. > > What was wrong with virtial/dev-manager and blocking !devfs if >=2.6.13 as we > discussed? Nothing at all. Thats how it is! > !staticdev?() <-- I know I don't really care for yet another new USE flag to > handle this. Thats the part I booboo'd. > An 'emerge static-dev' that can PROVIDE=virtual/dev-manager ; that just runs > ( cd /dev/ ; sh ./MAKEDEV generic ) seems like it would be an ok. > We probably just have to be sure portage does not remove device nods on pkg > removal/upgrades. OK, so you are also in agreement. The way it is is the way it should be (I asked nedd to comment as he is currently working with static /dev). Stefan, would you like to take this opportunity to write an ebuild for this? Or would you like me to go ahead and sort it out for you? I assume you're happy with the solution?
This solution is ok for me, I'll write the ebuild und put it here when ready. Is sys-fs ok as group for this? Sounds a little bit wrong, but since udev is also there..
sys-fs/static-dev sounds fine with me
sys-fs/static-dev sounds good to me too.
Stefan, Any news?
Sorry, had no time at all for this for personal reason, but will do my part at the weekend.
not a problem at all. Just wanted to check in :)
Any progress here?
Created attachment 72175 [details] static-dev-0.1.ebuild How about something like this? Is 'generic' alone good enough? Is it a nice balance between simple and bloat? Should we look at /proc/foo and make other device nods?
Created attachment 72194 [details] static-dev-0.1.ebuild Updated a little to make generic device nods for a arches. Note we dont install the nods in src_install() or use ${D} The reasoning for this is portage itself wont record or copy device out of ${D} The reason it's done in pkg_postinst() also is that if you happen to use root@shell # ROOT=/dev/shm/ROOT emerge -KO static-dev the device nods are still created proper and never recorded anywhere so it's all emerge -C safe.
This looks good to me. Its got my blessings.
solar, are you happy to commit that and close this bug?
I'll do this now, and I can sit as co-maintainer with solar, if he is happy to do so.
Added to the tree. I am now asking arch teams to test and mask as appropriate, please provide feedback through this bug. Cheers guys.
<snip from the ebuild> [[ -e ${ROOT}/dev/MAKEDEV ]] && makedev="${ROOT}/dev/MAKEDEV" || makedev="/dev/MAKEDEV" </snip from the ebuild> What if there is no /dev/MAKEDEV at all, for instance when a user is switching to a static devfs? Perhaps a HOWTO or README could be added to usr/share/doc/.
I'm guessing johnm(hoping) fixed those up to use the /sbin/MAKEDEV vs the /dev/ symlink that points back.
/dev/MAKEDEV should be a symlink to /sbin/MAKEDEV, so yes. /sbin/MAKEDEV is likely the better alternative, but if /dev/MAKEDEV doesnt exist then its still mounted over something else (tmpfs most likely by udev) and as such some hackery will be needed. mkdir /tmp/newroot mount -o bind / /tmp/newroot ROOT=/tmp/newroot/ emerge sys-fs/static-dev should suffice. I can likely push this into the ebuild - but how would you guys want it? some pkg_setup jiggery-pokery would work I guess, but it would be fatal. I'm not up for remounting root filesystems into sandboxes.
hrmm. We probably need a mkdir -p ${ROOT}/dev/ in there also for the case you just demonstrated.
assuming baselayout is installed or we came from some semi-sensible stage tarball /dev would already exist (albeit used as a udev/devfs mountpoint) We could add it in since it won't hurt, but it should exist in all cases.
Added a warning/kill to pkg_setup if installing over udev/devfs into CVS, this should avoid any major issues installing this package. Could arch teams please test and mark stable. Once all arch teams are done, please feel free to close this off.
looks like x86 was already handled
This works on my walnut, marked ppc stable.
stable on ppc64
go sparc.
Marked stable for hppa.
everybody has this stable, closing
