Bugzilla Bug 107875

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 an attachment (id=72175) [edit]
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 an attachment (id=72194) [edit]
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