well, turns out kde4 takes longer to make work properly than I would like. It still conflicts with kde3, which made building it with dpb difficult. And there are still lots of nasty small issues to fix, which means it can't replace kde3.
Due to its size, working out of tree is cumbersome. Thanks to the awesome work of Vadim, it's gone a long way, but it's still not quite there. So I've added really dirty tweaks to dpb to make it possible for kde4 to be a part of bulk builds. I MUST STRESS: I DON'T INTEND FOR THIS TO BE A PERMANENT SITUATION. Having the ports tree "fractured" like this is inconvenient. Specifically, there is no some extra code in dpb to "taint" hosts with kde3/kde4. And the corresponding ports in the tree will be marked as such (through DPB_PROPERTIES = tag:kde3 / tag:kde4) *this is not convenient to use*. There *is* no analysis. Ports that have the issue must be marked manually. I intend for this to remain a bit cumbersome: this is a make-shift solution, to allow work to proceed. Performance-wise, there are enough ports in the tree that splitting things this way shouldn't have any negative impact. But this does NOT mean it should ever be used for anything else. Full bulks from scratch will work. If you restart a bulk, and don't clean up installed packages before hand, things might go to hell: there is currently no recording in any lock/affinity of the kde3/kde4 property (this will probably change, as there are several other desireable properties I want to add in affinity locks, like building in memory and the workdir size). Full bulks CAN'T work on a box that has kde3/kde4 ports installed. You *must* build through a chroot then. How it works: - some ports are tagged. When they start running on a box, that box gets tagged. Other ports with different tags won't be able to start on the same box while a tagged job is running. - once the tagged build is over, the box is tainted. It will only be untainted if a junk phase happens while no tagged build is running. - obviously, tagged jobs won't start on a box tainted with a different tag. When no choice remains (nothing left in the queue), the job may force itself on the box, provoking a premature junk phase. This activity will show up in the engine as K: job postponed because of conflicting tag and C: job forced premature junking because of conflicting tag final details are getting ironed out. bulks testing is going on. when it's ready, kde4 is going to get built. I must stress out this is not yet production quality. This is direct fallout from EuroBSDcon, btw. Exchanging directly with Vadim made me rethink my take on kde4. With so many pieces still broken, switching to kde4 and phasing out kde3 now is deluded. And also that kde4 can only live so long outside of the official tree, where only a few people can make progress...
