What about starting to use project-builder for native packages?

Richard Bos ml at radoeka.nl
Mon Apr 19 20:22:09 CEST 2010

Op maandag 19 april 2010 06:47:53 schreef Gunnar Wrobel:
> Quoting Richard Bos <ml at radoeka.nl>:
> > Op woensdag 14 april 2010 23:34:02 schreef Gunnar Wrobel:
> >> Another reason for projectbuilder might be that we do not want to
> >> fully rely on an external build service. I consider it important that
> >> we are always able to build our own packages.
> >
> > This is very well possible as the code of the build service is fully open
> > source.  Just download it from:
> > http://gitorious.org/opensuse/build-service
> > But the build service software is course offered via packages, that have
> > been on the build service.  The can be downloaded from:
> > http://download.opensuse.org/repositories/openSUSE:/Tools/ ;)
> > As you can see in that repository, ISO's are being build and offered via
> > the build service as well.  This way you can host your own build service.
> >  This local build service can be connected with other build services.
> >
> > You should compare the build service as a code version repository, in
> > this case it is a package version repository with all the bells and
> > whistles.
> >
> > The openSUSE project offers free a free version of build service.  You
> > can freely use it, if you want.
> Ah, I wasn't aware of that. That makes it more attractive to me.

Last weekend there was a build service Meego meeting.  You can read a report / 
description of that meeting at this location

> >> The fact that it currently has no OpenPKG support also means we would
> >> have to wait a while until we can fully use it.
> >>
> >> Anyhow: You made it clear that you'd still rather like to go the
> >> OpenSUSE build service route. And I think it has the advantage of
> >> being an easy solution.
> >>
> >> But when I reconsidered the build service I thought we might also
> >> simply use both. As far as I understand it we only need decent spec
> >> files for the build service. Plus the source package. Is that right?
> >> Both are things that are being delivered by project builder. So it
> >> might be rather easy to do the basic template definition in the
> >> project builder and only generate the source package and the spec for
> >> the subsequent build service step. For all distros not supported by
> >> the build service we could fully build the packages.
> >>
> >> Do you think that might work?
> >
> > If you do it this way, you'll loose a lot of capabilities of the build
> > service.  Project-builder seems to be for one-man-band projects and
> > therefor smaller in scope.  If you compare PB to the build service it
> > apparently lack many of its features, for
> > example automatic rebuilding of dependent packages,
> As we always do full releases I don't see that as necessary.

Anyway you get it for free :)
An example when kolab-freebusy gets updated, and kolab depends on kolab-
freebusy, kolab gets rebuild as well.

> > package branching,
> As I'll answer in more detail in response to your other mail I don't
> think this will be something we'll use either.
> > project scoped user roles,
> I think this is currently just mapped to access rights to our
> repository. Which I assume would stay this way.
> > change request/review mechanism,
> We would certainly keep out issue tracker.
> > remote access to build logs,
> This might be nice for continuous integration purposes.
> > publishing control,
> Currently our publishing control is named "Thomas" :)
> > automation
> Maybe nice for continuous integration.
> > and user friendliness.

I just realized that the list is longer, 2 other things that come to mind are 
are the quality checks at the of end of each package build and there is a 
possibility of linking packages.  In other words the build service is 

> Agreed.
> Thanks a lot for your feedback! I'm more interested in the build
> service now than I am before. I still have a few doubts but I think
> the concerns I had here are answered. 

That is nice to read.


More information about the users mailing list