Seems I forgot to announce that the linux_base-c6 is in the Ports Collection now. Well, it is not a replacement for the current default linux base, the linuxulator infrastructure ports are missing and we need to check if the kernel supports enough of 2.6.18 that nothing breaks.
To my knowledge, nobody is working on anything of this. Anyone is welcome to have a look and provide patches.
Yesterday I deprecated the non-default Fedora based Linux base ports. This means fc6, f7, f8 and f9 will vanish soon (I decided for one month of expiry time). This is because all of them are End of Life upstream since a long time (= no security updates).
The fc4 and f10 ones are still available – even if they are End of Life too – because FreeBSD 7.x can not use something newer than the fc4 one, and we have not tested yet a more recent Linux distribution.
Probably the most easy way to update the Linux base ports to something newer is to stay with Fedora (we have a lot of ports-infrastructure for it already). Unfortunately it is not known if something newer works without problems (missing epoll/inotify support could be a roadblock here in case it is extensively used in a more recent version).
I want to get some time to have a look if a more recent Fedora version is suitable for the use as a Linux base in FreeBSD 8.x+, but I do not have an estimate when I can start and how long it may take. In case someone already tested a more recent Fedora version feel free to share your experience.
The package dependency speedup was committed by portmgr, unfortunately it was not the latest version of it. The most recent version is scheduled for an experimental ports build run (my patch also contains the possibility to switch of the registration of implicit dependencies, if enabled it gives a much better picture regarding which port needs to be rebuild (portrevision bump) in case a dependency changes).
Patches for speeding up “make clean” are also scheduled for an experimental ports build run. The pkg_create patch was also committed to -current.
With all those stuff an update is much faster now, at least for those ports where the compile/build time was much lower than the infrastructure processing (I doubt you will see a significant change in a build of OO 😉 ).
Ariffs changes two months ago to reduce the latency in the soundsystem also prepared the way for multichannel support and Yuriy added multichannel recording to the emu10kx driver (there are some bugs ATM and it is only a proof of concept to play around with it until we get real multichannel support in the generic sound code). Ryan tries to get some time (let’s cross fingers!) to convert a driver (probably the emu10kx driver) to use the new mixer infrastructure before he has to concentrate on his studies again.
This looks like we could get some very nice stuff this year.