PLDWWW: TODO/BuilderInfrastructure

[mmazur]

Author: mmazur   Date: Mon Aug 14 20:04:10 2006 GMT
Module: PLDWWW   URL: http://www.pld-linux.org/TODO/BuilderInfrastructure
---- Log message:
moooooore

---- Page affected: TODO/BuilderInfrastructure

---- Diffs:

================================================================
  
  The builder part of it is quite simple. The bin.builders should  be taught that every lets say 50 requests (on requests numbered 50,100,150...) it should send out a complete "rpm -qa" somewhere. The remote part of the system could then process that information and react appropriately.
  
+ This would be quite tricky however. The system would have to take into account:
+ 
+  # Arch specifications in spec files (ExcludeArch/BuildArch), doing this would requires cvs uping spec files using a given tag and parsing them.
+  # The src.builder would have to start providing information as to which packages were sent to which builders, so the system could take into account packages that weren't sent to all builders (sending packages to only a few selected builders without appropriate ExcludeArch/BuildArch in spec files isn't normal practice however, so this would work as a detection system).
+ 
  == General chroot cleaner ==
  
  The system mentioned in the previous point could also check for other stuff and take care of it (mostly by sending out requests for deinstallation and notices to developers) like the presence of -static packages (which from time to time could interfere with the build process, so it's usually better not to have them inside builders), presence of duplicated packages (usually they shouldn't be present) and any other potential problems we can come up with.
+ 
+ == Chroot annihilator ==
+ 
+ The "chroot cleaner" described above is in reality a litewight solution to the fact, that in a perfect world each package would be built in a completely clean environment, meaning after each build the chroot would be wiped allmost clean and when starting a new build, it'd only install required packages (depending on appropriate BuildRequires in spec files).
+ 
+ Our machines most likely couldn't handle such a solution, but there are alternatives -- it could for example wipe the builders clean only once in a while, thereby increasing the quality of the build environment without killing the machines.
+ 
+ The 'once in a while' part is tricky however. We really wouldn't want that to happen while in the middle of a major KDE upgrade or something like that, so there should be an option to suspend it until request is sent in for the suspension to be dropped. This again means, that it would have to be centrally controlled from the src.builder, with bin.builders just responding to a "wipe'em clean" type of requests.
+ 
+ Choosing this option over the one mentioned above is rather risky. It's obviously a lot more work and there's no telling how it would work out in reality (and if the gains overweight the potential for trouble this may cause; assuming we'd actually see any gains).
  
  == Write complete docs ==