[Kolab-devel] Debian packages, upstream source patching and quilt

[Paul Boddie]

On Friday 15. November 2013 13.20.46 Richard wrote:
> Jeroen,
> 
> Op donderdag 14 november 2013 23:21:21 schreef Paul Boddie:
> > That said, indeed should patches be in format 3.0 (quilt), but here be
> > dragons. OBS-originated dragons, to be precise. Since I said "OBS", I
> > feel I need not go in to any further detail. Suffice it to say we
> > deliberately set everything to format 1.0, and therefore void the use of
> > debian/patches/ (uch! and yuk!).

Just for reference, Jeroen wrote the above paragraph, not me.

> Did you share your experience with OBS on the OBS emaillist
> (http://lists.opensuse.org/opensuse-buildservice/)?

OBS is completely new to me, so I only intend to use it to submit packaging-
related patches back to the Kolab project. I imagine that for Kolab to get 
back into the Debian archives, which would be the most convenient solution for 
Debian users, the packaging would need to be exercised by various Debian 
tools, and this is why I was using tools that enabled me to contribute to 
Debian in the past.

It is possible that making packages exclusively using OBS is good enough and 
that the output from OBS will be just fine when uploaded to the Debian 
infrastructure, but there's no substitute for testing. I also wonder whether 
it is an objective to see Kolab packages in Fedora and Red Hat, for example, 
and what demands those projects' infrastructure makes on package construction.

Certainly, maintaining distribution packages externally can be done 
indefinitely, but the risk is that one ends up in the situation that I imagine 
OpenPKG created: that users regard the resulting packages as awkward and not 
completely compatible with the "proper" packages from their distribution, and 
so they are always regarded as second-class packages. At the same time, I 
appreciate that targeting lots of distributions shouldn't demand lots of 
administration time for different tools and services, and so I see that OBS 
definitely has a role to play.

Paul