Re: bringing sfcgal support to postgis
Bas,
On 09/04/2015 11:17 AM, Sebastiaan Couwenberg wrote:
Here we should clarify that the work in master targets Debian unstable
It does, among other distributions.
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.
That's one advantage, yes. At least equally important is the ability to
run older Postgres major versions on newer Debian versions. Upgrading an
OS is quick and easy, compared to upgrading a database (at least for
upgrades between major versions). That's why a lot of people still use
relatively old Postgres versions. PgApt allows users to upgrade Debian
w/o having to upgrade their database at the same time.
Because pgApt want to support older distributions with the same source
packaging they bound themselves to the lowest common denominator.
Given generation from templates, that's plain non-sense.
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.
PgApt is an attempt to extend and improve Debian. As you noted, it's
supported by active DDs. There definitely is a need for that in the
Debian project.
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.
..a task you're explicitly not willing to do, as you state below. Please
leave the how to those who actually do the work.
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.
I'm glad to hear that, thanks.
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.
Again: I didn't ever argue in favor of such an approach. It could break
things for Debian postgis users when adding the pgApt repository.
And I agree that sfcgal support should to be enabled with postgis-2.2
(across all Postgres major versions, starting from stretch and newer,
I'd say).
I only support Debian.
So does the PgApt project.
I understand you don't want to do any extra work for PgApt. That's very
understandable and perfectly fine. And I appreciate your work and
expertise in packaging for Debian.
Please don't reject PgApt as something entirely external to the project,
though. It's part of the bigger Debian project and something that allows
me (and others) to recommend Debian as a viable OS for running
PostgreSQL. (I would have to recommend another distribution, if PgApt
didn't exist.)
I'm also fine to let the pgApt packaging use the master & upstream
branches,
Yes, let's please go that route. 'master' should be the actual master or
the common source, not some specialization of it.
(That said, I do not object to keep debian/control committed in the
variant usable for sid. It's needed for uploads to unstable and doesn't
hurt PgApt.)
I can maintain simplified packaging branches based on that for
Debian because it doesn't need to care about the pgApt use cases.
Feel free to create branches as you like.
However, I ask you to please not over-simplify when uploading to
unstable, e.g. keep OR-ed build dependencies that are required to build
on old distributions. These things make it a lot simpler for PgApt and
don't break unstable.
Equally clearly, leaving out sfcgal would hurt sid. So please feel free
to add it (even on master, if you want). I'll take care of the PgApt
side (as I did before).
More generally: I'd like to continue working together - a common base
seems the most appropriate way to do so. You are more than welcome to
update and extend the package to better fit Debian/sid, as long as I'm
allowed to keep or add things needed for PgApt under the premise that
these don't break unstable. I don't mind if you occasionally break
things for PgApt.
Is that proposed path of action acceptable to you?
Regards
Markus Wanner
Reply to: