Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 107875 - Kernel now depends on virtual/dev-manager, but this is bad for static /dev
Summary: Kernel now depends on virtual/dev-manager, but this is bad for static /dev
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-02 04:54 UTC by Stefan Riemer
Modified: 2009-04-18 12:15 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
static-dev-0.1.ebuild (static-dev-0.1.ebuild,433 bytes, text/plain)
2005-11-05 06:44 UTC, solar (RETIRED)
Details
static-dev-0.1.ebuild (static-dev-0.1.ebuild,985 bytes, text/plain)
2005-11-05 08:54 UTC, solar (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Riemer 2005-10-02 04:54:18 UTC
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
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2005-10-02 05:40:48 UTC
So put udev into /etc/portage/profile/package.provided; I don't think that
static dev is supported at all.
Comment 2 Stefan Riemer 2005-10-02 07:29:53 UTC
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.
Comment 3 John Mylchreest (RETIRED) gentoo-dev 2005-10-02 07:47:32 UTC
(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.
Comment 4 Stefan Riemer 2005-10-02 08:49:46 UTC
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. ;)
Comment 5 Jakub Moc (RETIRED) gentoo-dev 2005-10-02 08:55:00 UTC
(In reply to comment #4)
> What about a use flag for static /dev? Or maybe a feature?

No, you can't inherit eclass conditionally.
Comment 6 Stefan Riemer 2005-10-02 09:03:40 UTC
(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)"
Comment 7 John Mylchreest (RETIRED) gentoo-dev 2005-10-02 11:38:11 UTC
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.
Comment 8 solar (RETIRED) gentoo-dev 2005-10-03 06:35:00 UTC
(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.
Comment 9 John Mylchreest (RETIRED) gentoo-dev 2005-10-03 10:25:18 UTC
(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?
Comment 10 Stefan Riemer 2005-10-03 14:23:52 UTC
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..
Comment 11 John Mylchreest (RETIRED) gentoo-dev 2005-10-04 08:04:39 UTC
sys-fs/static-dev sounds fine with me
Comment 12 Henrik Brix Andersen 2005-10-04 08:54:56 UTC
sys-fs/static-dev sounds good to me too.
Comment 13 John Mylchreest (RETIRED) gentoo-dev 2005-10-13 06:11:52 UTC
Stefan, Any news?
Comment 14 Stefan Riemer 2005-10-13 11:27:19 UTC
Sorry, had no time at all for this for personal reason, but will do my part at 
the weekend.
Comment 15 John Mylchreest (RETIRED) gentoo-dev 2005-10-13 13:17:20 UTC
not a problem at all.
Just wanted to check in :)
Comment 16 Daniel Drake (RETIRED) gentoo-dev 2005-11-05 03:53:50 UTC
Any progress here?
Comment 17 solar (RETIRED) gentoo-dev 2005-11-05 06:44:28 UTC
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?
Comment 18 solar (RETIRED) gentoo-dev 2005-11-05 08:54:40 UTC
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.
Comment 19 John Mylchreest (RETIRED) gentoo-dev 2005-12-30 10:10:54 UTC
This looks good to me. Its got my blessings.
Comment 20 Daniel Drake (RETIRED) gentoo-dev 2006-03-20 13:16:19 UTC
solar, are you happy to commit that and close this bug?
Comment 21 John Mylchreest (RETIRED) gentoo-dev 2006-03-20 13:19:30 UTC
I'll do this now, and I can sit as co-maintainer with solar, if he is happy to do so.
Comment 22 John Mylchreest (RETIRED) gentoo-dev 2006-03-20 14:02:22 UTC
Added to the tree.
I am now asking arch teams to test and mask as appropriate, please provide feedback through this bug.

Cheers guys.
Comment 23 Jeroen Roovers (RETIRED) gentoo-dev 2006-03-21 03:01:45 UTC
<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/.
Comment 24 solar (RETIRED) gentoo-dev 2006-03-21 04:01:22 UTC
I'm guessing johnm(hoping) fixed those up to use the /sbin/MAKEDEV vs the 
/dev/ symlink that points back. 
Comment 25 John Mylchreest (RETIRED) gentoo-dev 2006-03-21 04:42:52 UTC
/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.
Comment 26 solar (RETIRED) gentoo-dev 2006-03-21 05:17:34 UTC
hrmm. We probably need a mkdir -p ${ROOT}/dev/ in there also for the case you 
just demonstrated.
Comment 27 John Mylchreest (RETIRED) gentoo-dev 2006-03-21 05:26:19 UTC
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.
Comment 28 John Mylchreest (RETIRED) gentoo-dev 2006-04-15 01:04:05 UTC
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.
Comment 29 Mark Loeser (RETIRED) gentoo-dev 2006-04-21 20:15:43 UTC
looks like x86 was already handled
Comment 30 Joe Jezak (RETIRED) gentoo-dev 2006-05-01 07:12:08 UTC
This works on my walnut, marked ppc stable.
Comment 31 Markus Rothe (RETIRED) gentoo-dev 2006-05-02 22:57:59 UTC
stable on ppc64
Comment 32 Gustavo Zacarias (RETIRED) gentoo-dev 2006-06-26 13:10:36 UTC
go sparc.
Comment 33 Jeroen Roovers (RETIRED) gentoo-dev 2006-07-04 17:35:47 UTC
Marked stable for hppa.
Comment 34 Simon Stelling (RETIRED) gentoo-dev 2006-08-25 07:12:49 UTC
everybody has this stable, closing