not tagging emerge --info (not relevant, features have no affect on treewalks run) portage ver: 2.1.1_pre5-r3 , and 2.1-r2 (likely more, but that's what I tested). emerge udev; adds 3 device files, /lib/udev/devices/{console,null,zero} , those files *are* installed by portage, copied from ${IMAGE}. grep -H '/lib/udev/devices/' /var/db/pkg/sys-fs/udev-*/CONTENTS enjoy...
What udev version you're talking about? in udev-0.96-r1 I only see device file creation in pkg_preinst (and directly in $ROOT there), nothing in src_install.
eenie meenie, one that uses src_install for it; 087-r1 fex.
well, fixing that would be almost trivial on first glance, but comments on that code indicate that it's done on purpose, so this should probably go through -dev: if stat.S_ISFIFO(mymode): # we don't record device nodes in CONTENTS, # although we do merge them. outfile.write("fif "+myrealdest+"\n")
the disabling was done after device support existed then- portage still reads dev entries fine.
Maybe the purpose is to prevent collision-protect from complaining about device files. I can't think of any other possible reason atm.
(In reply to comment #5) > Maybe the purpose is to prevent collision-protect from complaining about device > files. I can't think of any other possible reason atm. Pretty sure that comment is older than collision-protect. Random guess is that it's another "unmerge protection" like with kernel modules, but I really have NFC.
(In reply to comment #6) > Pretty sure that comment is older than collision-protect. Random guess is that > it's another "unmerge protection" like with kernel modules, but I really have > NFC. At least as far back as 2.0.51.22, the unmerge code doesn't unmerge device files anyway. So, if it had anything to do with unmerge, it hasn't been a problem for a while now. So, the posibility of collision-protect annoyance is the only practical reason that I can think of not to go ahead and list them in CONTENTS.
It may have slipped in with one of the bulk lightly commented commits of the old days, but I'm pretty sure this has been around since I have - end of 2.0.49. The reason that device files are dealt with incorrectly may be a workaround for some other bug that no longer exists. It is just as likely that when support for device files was added, it wasn't added correctly...
This is fixed in svn r4588.
This been released in 2.1.2_pre2-r3.
