I’m writing this entry while I’m waiting for my pasta to get ready, in the lunch break I’m having between finishing some job task. For a series of reasons I’m going slowly at it because life in the past few days have been difficult. Adding to my problem with sleep, my neighbours resumed waking me up “early” in the morning (early by my standards, that is). Yes I know that for most people, 11am is not “early”, but given that I always tended to work during the night (easier not to be disturbed by family, friends, Windows users, …), and that they know that (not adding the fact that my father works shifts so he also works nights quite often), I wouldn’t expect such amount of noise.
With “such amount of noise” I mean that I get woken up, while sleeping with my iPod playing podcasts, the headphones in, with my room’s door closed. And no I don’t have light sleep, once I get to to sleep, unless I know I have to wake up (either to receive a parcel, to go to work remotely, or whatever). This weekend I ended up sleeping just shy of six hours per night, which is not good for my health either. I have now ordered a pair of noise-isolating in-ear phones, they should arrive tomorrow via UPS, they at least tend to be quite on time. On the other hand the Italian postal service, that should deliver me three Amazon packages, takes the usual eternity.
For what most of my readers are concerned, I still have my tinderbox running, after a few tweaks. First of all, Zac provided me a new revision of the script that generates the list of packages that need to be upgraded (or installed) in the system, which takes good care of USE dependencies so that when they are expressed I can see them before the system tries to merge them in. Then I’m wondering about the order of merge. Since I noticed that more than a couple of time I had to suspend the tinderbox run in the midst of it, the lower-end of the list of packages tended to not be merged as often as the upper-end (where quite a few packages I know still fail to merge). This time I executed the tinderbox from the bottom up (more useful since the sys-* packages are lower), but I’m considering next time to just sort the list randomly before feeding it to the merge command so that there are better chances for all the packages to be built in a couple of iterations.
Speaking about tinderbox and packages, I noticed that there are lots of packages that waste time without good reason, doing useless processing. This includes, for instance, compressing the man pages before Portage does so. While one can understand that upstream would like to provide the complete features to the users, it’s also usually a task that distributions do pick up, and would make sense to provide an option “I’m a packager” to not execute them.
Now, you could argue that those are very small tasks, and even for packages installing ten or twenty man pages it doesn’t feel like too much time wasted. But please think of two things first of all: the compression often enough is done with a for loop in sh rather than with multiple Make rules (which would be ran in parallel), serialising the build, and taking more time on multi-core systems. Secondarily, the man pages will have to be decompressed and compressed again by Portage, so it’s about three time the work strictly needed.
Another problem is with packages that, not knowing where to find an interpreter, be it Perl, Ruby, Python or whatever else, check for it in configure or with other methods and then replace it in all their scripts. And once again quite often using for in sh rather than Make rules. Instead of doing that they should just use /usr/bin/env $interpreter to let the system find the right one, and not hardcode it in the files at all (unless you need a specific version, but that’s another point altogether).
Well, I’ve eaten my pasta now (bigoli with pesto, for those interested), so I’ll get a coffee and be back to work. I’ll try to write a more useful blog later on today after I’m done with work. I have lots of things to write about, included something about XBMC (from an user standpoint, I don’t have time to approach it with the packager’s eye).
As usual very informative ;)Concerning build times: How about a real sh as shell? The configure step is a lot faster on FreeBSD where sh is not a link to bash. This would save time for every makerule that invokes a shell too./Andreas
Andreas, it’s something I do have in my queue of things to work on. Unfortunately it’s not as straightforward, as Javier could explain having seen it on G/FBSD.If you remember “I have written about the bashisms problem”:https://blog.flameeyes.eu/2… which is what stopped me in my first test.I need a much safer method to identify the problems, if I can find one one, it should be easy to replace @/bin/sh@ with a faster and lighter shell, even by default. But for now, not feasible.
Well, when I reread the post i remembered ;)It’s good to know that someone else is thinking on it though. And if it had been as straight forward I believe it would have been done, no way I’m the first to think about it…But maybe there are some patches against bashisms in the FreeBSD ports-tree. They would have had to deal with them already.Is there even a basic sh-implementation in portage?
The fact that bash is slow and heavy is something that is very well known, because the ebuilds are slightly slowed down that by that too.If you remember, Roy (uberlord) did a lot of work to avoid bashisms in init scripts, and OpenRC works perfectly fine when @/bin/sh@ is not bash nor bash-compatible (which is the case in Gentoo/FreeBSD for instance). He also wanted to avoid bashisms in ebuilds, but that might not be ideal (ebuilds aren’t usually overly long like a configure script and their execution time is not _that_ important).While FreeBSD does have patches for the problems, it requires first of all that they are found, and made sure they do work for our case. FreeBSD is unfortunately known for not making the patches generic enough for us to just import them as they are. Plus we have lots of packages they don’t have, and versions often bumped before they do. So it really calls for tighter control before we could go down that road.As for basic sh, we have @dash@ and probably a couple more.