Same method for toolchains is still in use, but has grown since that
documentation was written. We now also accelerate RPM installs and RPM
building - the most slow part of builds is the chroot setup.
Yes. I have spend hours of waiting and wondering how it can take so long
to get all "tex"-related packages to installed to arm chroot env in the
worker before the build itself can really start :-)
I believe significant speed up could be gained if the worker could have
a some kind of repository specific cache where the worked could save
the previously created chroot image.
Once the "next" compilation is done, that image could be used as a base.
OBS already handles the uninstall of non-needed packages as well as the
upgrade of changed packages to newer version. I would believe that in
most of the cases the creation of new chroot environment by using the
previous image would be faster than by creating it always from scratch
just before the build start.
I think following restrictions would be needed when implementing this:
1) Image would need to be saved to cache immediately after the
installation of all dependencies have been done. (To avoid the situation
that the previously build package would corrupt/pollute the image by
installing/overwriting something for example to /usr/bin)
2) Cached chroot images should be OBS build repository specific
3) Instead of saving the new image to cache after every build dome
against the certain obs repo (could be the first step), things could be
further speed up by adding some kind of more clever rules related to
cache image saving and handling. (Maybe it does not make sense for the
worker to save new cache image after every build for example, or there
could be for example the chroot images available for last 10 packages
build, or something similar...)
Mika
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
