Re: bringing sfcgal support to postgis
Bas,
On 09/03/2015 09:22 PM, Sebastiaan Couwenberg wrote:
But Debian and pgApt do not share the same sets of packages, so
divergence is expected. The workflow is pretty much the same.
Not the same set, no. But the single package should match. That almost
requires a common base. I don't care whether or not we commit some
intermediate step to a separate git branch (don't see much use for that,
either, though).
Create a branch from the most recent debian tag, modify the changelog
for backports distribution, build & upload.
Yeah, that's all well automated - to work from a common base branch
(usually master).
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).
Hm.. that may well be the case for backports, yes. However, only some
packages in pgapt can be considered backports. (You could raise a point
there, that the corresponding PgApt packages should better match the
backports. However, IIRC pgapt doesn't clearly guarantee to work with
other add-on repositories, including backports.)
Other packages - like postgresql-9.3-postgis-2.1 - clearly aren't
backport-ish, though. And postgresql-9.4-postgis-2.1 can come from
Debian or PgApt (depending which is published first) and these should
definitely work interchangeably.
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.
With a template approach, I see no reason for that, no. Just generate
the debian/control for the appropriated distribution. No need for
separate branches and multiplication of work.
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
Okay, so I happened to fetch the wrong sources? Those that aren't
capable of generating the debian/control file? I'm sorry, but that's a
good point against splitting anything and exactly the kind of confusion
I'd like to avoid. Let's please keep it all in *one* source tree for
packaging (for Debian and Ubuntu) - and automate those few adaption
required for different distributions. Maintaining an entirely separate
packaging tree for every distribution is a) unnecessary work and b)
prone to error.
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.
I'm not following, here, as I fail to see any balance. It seems messy to
me. Fortunately, PostGIS has no "upstream packaging"...
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.
But it raises a much bigger problem of multiplication of work and manual
synchronization, as the vast majority of the changes need to be applied
to *all* distributions.
Of course, I understand that it would get easier to only have to
maintain a package tree for sid. And maybe a backport. That would mean
dropping postgis from PgApt, though. Earlier, you proposed having a
separate branch for PgApt - like the backports. But whatever we use for
PgApt should better be able to come up with a debian/control file that
matches what's being uploaded to sid.
I'm sorry, but for these reasons, I remain unconvinced.
Regards
Markus
Reply to: