[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bringing sfcgal support to postgis


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.


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.



Reply to: