I’m not talking about web links but symlinks on the system. I’ve got to fix up the tinderbox as we speak – the dev-libs/mpc update broken GCC, I’m thrilled that soon enough a C++ library upgrade will be able to break the compiler entirely! – but before doing so I was checking what was around on that system. And it turns out that way too many packages use absolute symlinks, both when installing from makefiles, and when creating ebuilds.
And there are more problems as well: a ton of world writable directories are also to be found on my tinderbox as it is, mostly in /var but not limited to. How many of these could be exploited for security issues, and how many of these are much less warranted than the stuff the hyped security guys focus on? Probably lots. Should I start reporting all of these as bugs? Possibly, yes, but I’m not sure if I’d be listened to, and for many packages the solution is going to be a very simple “drop the package as nobody’s interested”.
After this there is much debris that is there because upstream doesn’t understand how to properly install files on a Linux system. Sometimes there’s little you can do about it, as you need to keep it around for compatibility, but many other times, it’s extremely helpful to actually move things around in such a way that you don’t pollute the directories that, for instance, the linker has to search through to find the runtime libraries.
One very quick example about this latter situation is for instance move the daemons’ binaries out of /usr/sbin into /usr/libexec or whatever else you prefer (/usr/lib/${PN} works for me just as fine, it’s just a bit more arcane), so that it doesn’t pollute the path space for the root user. Especially when said daemons have no way to be executed in foreground for debug purposes.
At any rate, this is yet another piece of the puzzle that the tinderbox is helping to solve, so thanks again to all the people who contributed to it, the work is in progress (and yes, I did solve the mpc issue; bugs will resume flowing).
Given the GCC people decided that was fun playing with that language the outcomes are:- enough people caring about C and just C will fork from the latest C version once they get fed up of a compiler more broken than clang.- by dogfooding C++ we’ll get a stabler runtime.- Massive switch to llvm+clang and possibly a balance of powers within that project.- pcc gets more attention and people might even try to use it.I’ll keep a gcc-4.7.2 around for when I’ll need to bootstrap a broken compiler due stdlibc++ being horrible.
There’s nothing more annoying than broken links! I would have to say that it’s one of my nerdy pet peeves – especially when it’s so easy to run a link checker and remove them!