Re: bringing sfcgal support to postgis
On 03-09-15 20:30, Markus Wanner wrote:
> On 09/03/2015 06:05 PM, Sebastiaan Couwenberg wrote:
>> We can take a similar control template approach as qgis does for its
>> supported distributions for example. Or maintain separate packaging
>> branches for Debian & pgApt in git. I prefer the latter.
>
> I'm a bit afraid of mismatches between the two, if we split into
> different branches. For users of PgApt, it shouldn't matter whether they
> got the package from Debian or PgApt. That's a lot easier to guarantee,
> if the two are built from the same set of source files.
But Debian and pgApt do not share the same sets of packages, so
divergence is expected. The workflow is pretty much the same.
Create a branch from the most recent debian tag, modify the changelog
for backports distribution, build & upload.
When the Debian package gets updated to a new upstream release or other
interesting changes are made, merge the new debian tag into the
backports branch preserving the backports changes (e.g. different build
depends, configure options, branch in gbp.conf & Vcs-Git URL, etc).
If you don't want more than one branch for the different pgApt
distributions you'll need to drop the sfcgal dependency than will be use
for the Debian uploads.
> Apart from that, what problem would git branches really solve? AFAIK
> there's no way to force generation of a control file *before* its
> Build-Dependencies are processed (in Debian proper). To have a git
> branch that matches what's uploaded, we therefore commit the
> debian/control file for the sid variant - even though it's
> auto-generated (meaning something you usually shouldn't commit). AFAIU
> the PgApt case, the 'clean' target (or maybe just the debian/control
> one) is executed before evaluating B-Ds, which allows us to generate
> (and override) debian/control, there.
>
> I'm very open to discuss changes to *how* we generate the control file.
> (To the point that we'd actually maintain a control file for each
> distribution and the "generation" would then barely consist of copying
> the right file in place.)
>
> The qgis variant looks interesting, however, I couldn't figure how to
> actually generate the control file.
The gentemplates target is only available in the upstream packaging,
they use it along with control.in and friends to generate distribution
specific packaging.
https://github.com/qgis/QGIS/blob/master/debian/rules#L166
We have a reasonably good balance with upstream using the templates for
their packaging and Debian using the normal packaging for ours. The QGIS
packaging is complicated by upstream shipping their own packaging, so
the packaging changes need to be merged every time a new upstream
release is imported.
PostGIS doesn't include debian packaging to complicate packaging, but
has a similar use case wrt targeting multiple distributions. Using
separate packaging branches simplifies the packaging by not having to
care about being usable without changes on older distributions, no need
to generate packaging just make the changes in the distribution branch.
> BTW: I didn't see the patch from the OP, as I'm not on debian-gis, just
> pkg-grass-devel.
The patch is just adding libsfcgal-dev to the Build-Depends.
I encourage you to subscribe to debian-gis@ too, it gets more relevant
traffic than pkg-grass-devel@.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: