Re: OSTree hosting

[Colin Walters <walters verbum org>]

On Fri, 2012-01-27 at 23:29 +0100, Vincent Untz wrote:

> Whether it could be used to build things the way Colin has designed
> OSTree is something I don't know. It might not be able to support other
> features Colin has in mind, though (either because it's, well, "just" a
> build service, or because it's really not compatible by design).

So...to be honest the server side build scripts are just a lame set of
Python scripts.  I certainly don't think they're interesting.  In
theory, one could teach OBS how to generate "artifacts" (which are
really just tarballs of binaries).  If OBS already abstracts over
dpkg/rpm, then it could probably do OSTree too, and certainly I'd love
to help someone improve the build server part.

> I'm sure OBS could be used to do something amazing for GNOME, but until
> someone does the work, nothing is going to happen there ;-)

*However* what one absolutely can't use OBS for is part of my
edit-compile-debug cycle.  If I had to shuffle my code over to OBS, wait
for some VM to be booted, unpack the source tarball, run make, create
rpms, wait for a repository to be created, and then wait for zypper to
download the resulting RPMS every time I wanted to edit some C code, it
would basically drive my productivity to zero.

In other words, OBS doesn't replace jhbuild.  OSTree does.  My *local*
build system is incredibly fast *and* safe.  Faster even than JHBuild,
and *way* faster than RPM's "mock" or dpkg's "pbuilder" type tools.  I
set up a hardlink farm, slap a read-only bind mount on top, chroot in,
bind mount outside to the unpacked local source tree, run make, and then
you have a set of binaries you can overlay on top of the running system.

But you still have rollback; a quick "ostree reset" and you'll have
undone your local changes.  (Ok the reset isn't implemented yet since I
am still working through some earlier bugs, but it really will be
trivial).