On 28/01/11 03:36, Thomas S Hatch wrote:
I have been passively working on a similar project called quarters, but I
must admit that my motivation is somewhat low not knowing if the project is
in demand. So here is my question, do we think that something like this
would be a benefit to Arch? Is this the type of project that should merit my
attention?
An automated build system, in particular for the big rebuilds we do, has
been discussed among the developers many times. So there is definitely
interest in such a system.
Also, if we do think that this would be a good thing to have for Arch, I
would like feedback on what types of features the system would have and how
it would behave. Right now I am following the idea of supporting a
distributed build system so that we can have any number of build servers in
the fray working away to produce Arch packages for us. I am also attempting
to build it in such a way that a database is not required and that the
interface would be amazingly simple (this is Arch after all). This would
mean that by mearly checking into svn a package would be built, and then an
interface would pop up for the right people to sign it off, and once it has
been signed off it would move over.
I have never liked the idea of automatic building after a SVN commit.
There a plenty of times that commits are made to SVN in preparation for
an update at a later time. Instead, I would prefer a command-line queue
submission tool (local or remote...). You could have it flexible enough
to take a "makepkg --source" tarball, or allow configuration for
updating then building from a SVN/git/etc repo.
Thinking about what I do in packaging (and as someone who does not use
the AUR), I see the following situations that need to be covered:
1) single package build: This would probably be the majority use case
2) multi-package build: Sometimes packages come in pairs/groups where
updating one requires updating the next. e.g. tcl and tk. That
requires building tcl, adding the new package to the chroot and then
building tk.
Note there could be cases where this is more complicated... e.g.
Updating package A,B,C,D. A is required for B, B is required for C and
B is required for D. Note that installing C in the chroot after
building would be unclean for the build of D. Think updates to desktop
environments as an example of this.
makechrootpkg has the facility to add packages to a local repo after
being built, so that could be used to implement this.
3) big rebuild: e.g. for library soname bump. There are two types of
builds here. A) the initial builds and B) all the packages requiring
rebuild because of those in A. For B, automatic pkgrel bumping would
be good. Also, some automatic determination of the build order for B
would be very helpful. This would require error handling as if a
package low in the dependency chain fails, the rest of that chain should
not be built. Again, adding the packages to a local repo as the rebuild
progresses will allow to build packages cleanly against those that are
already rebuilt. Also not that there could be no packages in list A
(e.g. if we just want to rebuild all of [core]).
4) flexibility to add makepkg paramaters: I'm not sure how widespread
use this would get...
e.g. the toolchain is built in the following order:
linux-api-headers->glibc->binutils->gcc->binutils->glibc
The first glibc and binutils builds will be built with the --nocheck
option in the future. The gcc and final binutils and glibc builds are
built with -L to save the testsuite build logs. I guess you would make
-L the default anyway and have them available at the end of the build
for inspection.
Anyway, #3 is what I consider most important in an automated build
system designed to make the job of packaging in Arch easier. It is also
the level where I would start using such a system.... Building a
single package locally is a two "makechrootpkg" commands (one per
architecture) and I do not have to transfer the resultant package to
test. So I doubt I would use a build system for that (unless build time
was massive) as I can not see the automated build being more efficient
for me.
Allan
