[Kolab-devel] Announcing some blog posts for building packages for Debian on OBS

Tue Oct 29 18:41:34 CET 2013

On 2013-10-29 14:36, Mateusz Kijowski wrote:
> Hi,
> 
> 2013/10/28 Paul Boddie <paul at boddie.org.uk>
>> I was wondering which project we should be targeting. I see there are 
>> "3.1"
>> and "Development" projects, and when I tried to build the 
>> "Development"
>> packages myself there seemed to be some kind of fundamental 
>> (non-packaging-
>> related) build issue, whereas the "3.1" packages didn't exhibit the 
>> same
>> problems.
>> 
>> If we're fine-tuning the packaging is it best to target "3.1" in order 
>> to
>> not
>> have to deal with two different variables at the same time, or should 
>> it be
>> safe to target the "Development" stuff? Also, where do the "Updates" 
>> come
>> into
>> this?
>> 
> 
> I am also confused by this. Which project should people willing to help
> with Debian packaging should work with? I am under impression that
> following a moving target (which I understand Kolab:Development project 
> is)
> is flawed. I think that we should focus on getting 3.1 packages to 
> shape
> and then port necessary changes to the development project.
> 

I would argue that one should always target the next version of Kolab, 
i.e. Kolab:Development, not unlike new packages for Debian first must be 
accepted to Sid (the moving target), before they can become available in 
testing, or backports for stable.

That said, I'm more than willing to entertain first fixing the packages 
for Kolab:3.1(:Updates), as long as some of you are willing to stand up 
and make sure fixes also end up in Kolab:Development (immediately or 
afterwards).

> I also have trouble to actually understand how Debian packages are 
> being
> built here. Let's take the pykolab package:
> 
> pykolab$ ls -al
> razem 392
> drwxr-xr-x 3 matik matik   4096 paź 29 13:57 .
> drwxr-xr-x 4 matik matik   4096 paź 29 13:57 ..
> -rw-r--r-- 1 matik matik  10467 paź 29 13:57 debian.changelog
> -rw-r--r-- 1 matik matik   3370 paź 29 13:57 debian.control
> -rw-r--r-- 1 matik matik    640 paź 29 13:57 debian.rules
> -rw-r--r-- 1 matik matik   7094 paź 29 13:57 debian.tar.gz
> drwxr-xr-x 2 matik matik   4096 paź 29 13:57 .osc
> -rw-r--r-- 1 matik matik 333461 paź 29 13:57 pykolab-0.6.8.tar.gz
> -rw-r--r-- 1 matik matik   1086 paź 29 13:57 pykolab.dsc
> -rw-r--r-- 1 matik matik  14742 paź 29 13:57 pykolab.spec
> 
> I understand that debian.tar.gz is the debian directory from the source
> package. This layout is quite different from what I am used to when 
> working
> with debian packaging so I have some questions regarding this file:
> 
> * Why is it a tar and not a proper directory?

osc, the OBS command-line client and source code management utility (#50 
points of FAIL), does not support directory trees.

Not proper, agreed.

Entirely awkward, agreed.

Not entirely sure why the OBS developers would come up with such a new 
niche corner of the universe specific to them and them alone, either.

> * Why there are some files (debian.{changelog,control,rules}) separated
> from the debian.tar.gz?

OBS itself requires these .dsc, .changelog, .rules and .series and such, 
for fsck knows what reason.

OBS requires exactly two tarballs, no less, no more, and both need to be 
referred in the pykolab.dsc either using format 1.0 and zeroed out 
checksums and sizes, or format 3.0 and accurate checksums and sizes. 
Perhaps read on down for further info.

> * What connection does it have to
> git://git.kolab.org/git/pykolabreferenced by pykolab.dsc? (in fact
> this URL seems to be broken)

This is the upstream source code management repository.

> * Does this have any connection to http://git.kolabsys.com/apt/pykolab/ 
> git
> repository?

This is the former APT git-buildpackage source code management 
repository.

> * Is debian.tar.gz generated somehow? According to Timotheus' how-to 
> [1]
> one should untar it, make changes to the files inside, tar it again and
> push for building. Are these changes kept in some kind of version 
> control?
> 

The server-side of `osc` can indeed look in to the .tar.gz, but the only 
means of creating revisions is by submitting a new .tar.gz.

> Also, some packages (e.g libkolab) seem to have patches inside them. I
> guess that they are needed for RPM generation from *.spec files. Is 
> that
> true?
> 

If there is a debian.series, they may also be used for the Debian 
packaging.

> I am also wondering where the pykolab-0.6.8.tar.gz file is coming from.

http://mirror.kolabsys.com/pub/releases/

> I
> guess that some of these questions are related to inner workings of 
> OBS. I
> am willing to learn, but I have trouble to find relevant information. 
> Could
> you point me to some information on how this is all set up and/or how
> building works in OBS? Some kind of build script might suffice, but I'm
> unsure where to look for it.
> 

The upstream documentation from build.opensuse.org applies cleanly.

That said, however, do not mistake OBS for a decent build system. On a 
scale from one to ten, OBS would probably score a mere two points. It 
has no tags, no branches, no distributed version control, very limited 
access control capabilities with an architecture that would make your 
bald uncle's hair stand up straight and makes you boggle at the tricks 
you need to pull if you are anywhere near familiar with how a build 
system is supposed to work.

Highlights:

   - project configuration, seeded to an OBS-specific buildroot-creator 
utility in one go, overrides your package manager,

   - the buildroot-creator is called once, based on what an OBS-specific 
interpreter thinks of your package description, rather than populating a 
minimal buildroot with packages as they are available on native build 
system suites, to then interpret the specifications of your packaging 
the way that a native build system suite would do it.

   - although I do have access to the sources of Kolab:13 (for which I 
need to be both a maintainer and a reader, BTW, as the hogher-level 
privileges to not imply not include the lower-level privileges, however, 
how can one be a maintainer without access to the sources), I can still 
not download the source package (.src.rpm etc.),

   - releases (as in NEVRA releases) are overwritten causing you to need 
to work around the issue of possibly having two entirely different, 
binary incompatible foo-1.0-1 packages, which may have been build 
against two entirely different versions of Linux / GNU/Linux.

   - it requires complete copies of mirrors and therefore cannot include 
updates to distributions.

I could go on for a little while longer...

It works, but turns out packages of relatively low quality. The way it 
manages the sources for packages and packaging is far worse, as you have 
experienced. It's an entirely new ball-game.

If I ever have some spare time on my hands, I'll dust off the build 
system design I created a couple of years ago, but never got around to 
actually implementing.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08