Thanks Allan, I will look at pacbuild. Jelle, as for AUR interactions, this would not be a primary use by any means, I think that serving the core Arch repos would be top priority. There are a lot of ideas about interacting with the AUR, but I think that resource wise and logistically it should in nowise be considered the primary focus. With that said, I think that making the builder as pluggable as possible will allow us to grow into these roles if we see them as useful in the future. As for the behavior of the build process wrt releases, I think that we are going to have to really iron that out, we have a lot of ideas on how to do it. I think that we need to list out these ideas and, as a community, decide on how we want to move forward. An automated build systems in not just a "convenient way to build packages" it is a quality control gateway for the distribution, a verification checkpoint for package quality and consistency. We need to figure out how to approach this process in light of having such a gateway. Jakob, YES! You are spot on here, one of the main motivations behind a system like this is security. While I don't think that this is a problem with our developers, I do think that it is a potential future problem, Arch is continuing to grow and at an exponential pace. Security of Arch packages is going to be an increasing issue. I don't want to open up the subject of package signing here, but as a side note, a build system could greatly aid aspects of security ranging from quality control to package signing and software verification. All in all the discussion here has brought a lot of questions to light, I am writing up a design proposal on the wiki, but so far it has only touched the software design aspects and not the fact that this system will almost definitely have ramifications on the software release process. Thanks! Keep the comments coming! -Thomas S Hatch
