Re: bringing sfcgal support to postgis
On 04-09-15 08:48, Markus Wanner wrote:
> On 09/03/2015 09:22 PM, Sebastiaan Couwenberg wrote:
>> 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).
Here we should clarify that the work in master targets Debian unstable,
packaging targetting a different distribution and/or archive should live
on its own branch. The work for Debian unstable is leading for the
targets that branch off from there.
>> 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.
pgApt for Debian unstable is mostly irrelevant except for the different
PostgreSQL releases it supports. Its support of newer upstream releases
on older distributions makes it alot like backports, that's were its
value lies.
Because pgApt want to support older distributions with the same source
packaging they bound themselves to the lowest common denominator. In
this specific case that's not using sfcgal until its available on the
older distributions too. And this is a divergence from Debian which can
and will support sfcgal without needing any tricks.
I don't like 3rd party repositories because they complicate packaging
and seldomly integrate properly with the distribution making them a
source for bugs and upgrade issues. pgApt is one of the best managed 3rd
party repositories, but I still cannot endorse its use because of the
problematic nature of 3rd party repositories. I'm likewise unhappy with
the upstream QGIS and GRASS packaging for example. With QGIS we've found
a reasonable balance, with GRASS the situation is still terrible.
>> 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.
But the templates are only required to support the pgApt use case,
Debian has no need for it. I therefor strongly prefer to not have to
deal with pgApt complications because Debian does have a sanely
integrated archive.
This automation fetish of wanting to use the exact same source packaging
for different distributions is overly complicating a workflow that's as
simple as merging relevant changes from Debian.
>> 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.
But this is all unneccesary for Debian, it's only required for 3rd party
repositories that want to do something else than Debian. That's why I
discard the templates stuff for QGIS because we don't need it. I do try
to merge our improvements back, because upstream developers aren't as
good at packaging as Debian people are (hence the sucky nature of 3rd
party repositories).
I don't see how a separate branch is prone to error, only when you don't
know what you're doing are merging changes in git a source for errors.
You are competent enough to not need this excuse I'd say.
>> 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"...
The QGIS situation is still messy yes, but much better than it was
before when only the QGIS developers were working on the Debian
packaging. Merging new upstream releases is much less problematic wrt to
dealing with the debian packaging included in the upstream source.
Before I largely rewrote the packaging, it wasn't good enough to pass
FTP master review. Leaving users only the upstream repository to get
qgis packages, not a good situation for our users.
I'm very happy that the PostgreSQL ecosystem takes as much saner
approach for their 3rd party repository, and actually has DDs involved
which is reflected in the package quality.
>> 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.
I think you only need a single packaging branch for pgApt, with one
difference with the Debian master branch: not including sfcgal to not
need packaging changes for the older distributions.
The pgApt packaging branch will still share the same upstream &
pristine-tar branches, it just needs to merge the changes from the
Debian branch whenever it wants to incorporate changes from Debian.
> 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.
The solution for pgApt is up to you, I only support Debian.
I'm also fine to let the pgApt packaging use the master & upstream
branches, I can maintain simplified packaging branches based on that for
Debian because it doesn't need to care about the pgApt use cases.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: