Source Services 0.0.1, no more writing SPEC files ?

Okay, my first example of the build service source services did something usefull on my notebook. I submitted a very short file and I got installable packages in return. The file is actually that simple that it can easy get created by any IDE, website or desktop shortcut.

So the final goal is to get a 1-Click package build, but there is even more !

This was my test file:

<services>
  <service name="download_url">
    <param name="host">fotowall.googlecode.com</param>
    <param name="path">files/fotowall-0.7.1.tar.bz2</param>
  </service>
  <service name="generator_qmake" />
</services>

It lists two services offered by my local build service, the “download_url” service is downloading the file from the server. This is important, because we can ensure via this mechanism that our tar balls are really comming from a certain server and are not repacked by someone.

The second service is a spec file generator. Unlike former attempts where people tried to write one general purpose generator, this one is high specialized, in the case for qmake files. In fact, it is acctually a hacked qmake, this avoids that we need implement our own .pro file parser and interpreter. This means it is way more easy to write a generator without the need of all the internal knowledge.

Last but not least there is a first library package, which maps link calls (eg -lqt) to package names. In this way the qmake generator can easily create proper BuildRequire lines.

All this stuff is available in svn and openSUSE:Tools:Devel project. If you like to write another source service, you may want to look into the obs-service packages there. They are for sure no master piece of computer sience yet, but they prove the concept. It should be relative easy to write

  • svn/git checkout service
  • md5 or gpg validator
  • cmake base spec file generator
  • specialized autoconf/automake code generators
  • Java ant based code generator
  • Perl cpan based code generator
  • You have for sure another idea 😉

I will for sure not work on all the other code generators and further stuff, so any help is highly welcome !

You can already install these services on your workstation and run them manually. No need for a running build service instance. I will play around with the qmake generator first and try to solve general open problems like

  • Get License field set
  • Getting RPM Groups handled somehow
  • Survive desktop Category check better (most likely by fixing our menu config file, it seems not to be maintained since quite a while).
  • Handle package splitting (esp. for library packages).
  • Getting descriptions from package meta data.
  • Improving the library link to package mapping.

But before, I will rewrite the bs_service daemon in a more secure way, so that we can actually deploy it on build.opensuse.org 🙂

So you see we are still at the beginning, I hope some of you join the development. It would be extremly powerfull, if we just need to throw a URL at the service to get packages in 90% of the cases 🙂

Advertisements

About adrianS
works on OBS OBS (openSUSE Build Service), but spend some residual time also with sailing, music and of course lots of car driving.

8 Responses to Source Services 0.0.1, no more writing SPEC files ?

  1. Richard Guenther says:

    Please add a mandatory field for a MD5 sum that is required to match that of the downloaded sources
    (which could then of course also be used to implement a build-service-side caching mechanism of the
    downloads, but that’s secondary).

    • Adrian Schröter says:

      As written my current thinking is that validating, eg. via a md5 (or better sha1) would be an extra service. I do not see why it must be mandatory in the downloader service, since all of this files became anyway part of the source repository. So you can also see afterwards when it has changed.

    • Adrian Schröter says:

      and it would break use cases like downloading a -latest.tar.gz link.

  2. Srinidhi says:

    Hey Adrian! Very cool! I’m willing to help out.

  3. It’s very pleasant to finally see that some efforts go against duplication of efforts. I’ve always seen spec files and tools like jhbuild a way of doing the same thing twice.

  4. BTW, please indicate in your spam protection system that the number has to be written with digits!! I’ve been trying to put a comment like five times (writing things like “five” or “f-ive”, when I should have written “5”).

  5. Mike Cronquist says:

    Thanks. Testing comment field.

  6. Livio says:

    Would be awesome to stop writing SPECs, they’re boring and useless. It takes a lot of time to write a SPEC. Packaging for Linux takes much more time than creating an installer, it needs to be quicker and smarter 🙂 .

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: