For example, on media-libs/netpbm/netpbm-10.48.00-r1.ebuild, line 91, we have this: cat config.mk.in /dev/stdin >> config.mk <<-EOF Which can be safely changed to: cat config.mk.in - >> config.mk <<-EOF Here is an excerpt from `man cat`: With no FILE, or when FILE is -, read standard input Another excerpt: cat f - g Output f's contents, then standard input, then g's contents. This way is even cleaner, and removes that unnecessary dependency. This is the only ebuild on portage that depends on it as far as I know, so it's definitely odd. Reproducible: Always
Created attachment 213264 [details, diff] fix described in the original report
your system is unnecessarily broken
Sorry, my system is what? I'm not reporting any bugs on my system.
if your system doesnt have /dev/stdin, then it is broken
And I never said it did not have, and it is not relevant. This enhancement/cleanup stands regardless. Here is a result of `fgrep -rn /dev/stdin /usr/portage/*/*/*.ebuild` /usr/portage/media-libs/netpbm/netpbm-10.46.00-r1.ebuild:94: cat config.mk.in /dev/stdin >> config.mk <<-EOF /usr/portage/media-libs/netpbm/netpbm-10.48.00.ebuild:90: cat config.mk.in /dev/stdin >> config.mk <<-EOF That's really the only ebuild which does this. Maybe you are complaining that the severity is wrong? If that's it, then sorry, fixed now.
the answer is still no. random things utilize /dev/stdin (not just in the ebuild tree), so if a system is missing it and emerging netpbm finds the problem, then all the better.
That's a terrible excuse actually. Do you go around making your code randomly depend on redundant features of the spec just so that it can break on spec violating systems? That's how stuff gets deprecated actually, when it's redundant and nobody uses it anymore. You have any other examples of stuff depending on /dev/std stuff, even non-ebuild things?
Personally I see no reason why respond in such non-friendly manner. The suggestion is reasonable, because it (a) improves code readability and (b) saves one open() and close(). Provided that the change semantically changes nothing, it is definitely not worth arguing about. The counter-argument provided doesn't seem so strong also, because the goal is to emerge media-libs/netpbm and not to assess host system sanity. This is just my subjective opinion, so please feel free to ignore it. :-)
frankly, i dont care. i'm not saying none of your reasons are invalid, just that it doesnt really matter. /dev/stdin is a perfectly acceptable method for reading stdin and is infinitely more readable than a plain "-".
Frankly, if it is more readable, other developers should be aware of it, because on my test system with lots of packages installed, that ebuild is the only user of /dev/std* Would you take a patch changing all users of "-" to use /dev/stdin then?
i'm not going to tell other people what code style to use. if they want to use /dev/stdin, that's their choice. since this is obviously going nowhere, this is my last comment on the issue.
That's one unnecessary feature which will now have only one odd random user because you couldn't care less. Frankly it's a shame that so much needs to be argued about a simple text replace. Good luck on your endeavor of making portage a successful system sanity checker.
*** Bug 339267 has been marked as a duplicate of this bug. ***
*** Bug 363181 has been marked as a duplicate of this bug. ***
*** Bug 363193 has been marked as a duplicate of this bug. ***
SpanKy, as we can see there are people having the same problem. I don't know they have "broken system" or everobody else has magic system with /dev/stdin. Maybe it would be nice to spend some time to find out what is going on on "broken systems", how to fix it (no, users dosn't do rm -rf /dev/* to add work for gentoo devs). I can imagine ebuild fo netpbm could done in diffrent way, so people with "broken system" would do 'emerge netpbm'!:) But no.. Let's them have a problem, i don't change anything in ebuild because _i'm always right and i'm Big, Greate Gentoo Dev_ . If i was unpollite - i'm sorry, but this is how i can see your behavior with this bug.
for the sake of it, since all currently new installed Gentoo systems seem to have the problem and for reference :) look here: http://forums.gentoo.org/viewtopic-t-879897-start-0.html udev needs to be added to the runlevel: rc-update add udev sysinit this creates the needed devices and it builds fine...
It's not solution in my case :( : # rc-status sysinit Runlevel: sysinit dmesg [ started ] udev [ started ] devfs [ started ]
(In reply to comment #19) > It's not solution in my case :( : > > # rc-status sysinit > Runlevel: sysinit > dmesg [ started ] > udev [ started ] > devfs [ started ] Sorry for the late answer, I didn't subscribe to this bug :/ Why is there both, udev and devfs? They have different naming for devices, I imagin first udev maps a /dev and then devfs maps another /dev over it. Try to kick out devfs :) http://www.gentoo.org/doc/en/devfs-guide.xml 'Warning: devfs is obsolete and has been removed from the stable 2.6 tree in the 2.6.13 release. Users on 2.6 kernels are hereby advised to switch to udev. For further information on udev, please refer to the Gentoo udev Guide.'
In devfs init script is: [...]for x in "devpts /dev/pts 0755 ,gid=5,mode=0620 devpts" "tmpfs /dev/shm 1777 ,nodev shm" ; do [...] So this script mount (if it isn't mounted already) /dev/pts and /dev/shm. Moreover devfs in sysinit default in stage3. Meseems removing devfs from sysinit change nothing in this case.
(In reply to comment #21) > In devfs init script is: > [...]for x in > "devpts /dev/pts 0755 ,gid=5,mode=0620 devpts" > "tmpfs /dev/shm 1777 ,nodev shm" > ; do > [...] > > So this script mount (if it isn't mounted already) /dev/pts and /dev/shm. > Moreover devfs in sysinit default in stage3. Meseems removing devfs from > sysinit change nothing in this case. I installed a system last weekend and ran into the same problems, had to create device node etc. The current (09/06/11) default stage3 is broken... this should help: https://bugs.gentoo.org/show_bug.cgi?id=368597 http://forums.gentoo.org/viewtopic-t-880149.html
I've changed it to - now instead onf /dev/stdin. In general, if you don't have /dev/stdin, your system is broken. /dev/stdin is perfectly valid usage. That said, I've seen cases where /dev/stdin was missing (incl some stage tarballs before devtmpfs/udev start), and - worked fine instead. Just avoid the problem and fix it from all ends.
Robin, thanks a lot for fixing this annoying bug. I don't understand why user experience has such low meaning and such simple fix/workarround needs almost 2 years to be done. Thanks once more.
as pointed out many times (including the comment you just replied to), a missing /dev/stdin is a broken system. blaming netpbm for your broken system is misguided and wrong. end of story. having netpbm visibly fail is an advantage: you are clearly made aware of the issue so you know you have to fix it. other scripts often times do not fail cleanly or even noticeably.
