Re: bringing sfcgal support to postgis
Hi Markus,
On 04-09-15 15:48, Markus Wanner wrote:
> On 09/04/2015 11:17 AM, Sebastiaan Couwenberg wrote:
>> 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.
Yes, very good point.
>> 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.
Because I don't like generating packaging with templates, I ruled out
that option of possible solutions. I have a strong preference to simple
solutions, and not adding sfcgal until all target distributions include
it is one of the simplest solution. But I agree that not adding it for
distributions that do include it is undesirable for pgApt as well.
Maybe we should do both. Generate the packaging branches in git to not
need dynamically generated packaging in the source package itself. We
should be able to automate much of the git packaging workflow.
>> 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.
For pgApt it's a shame that it cannot be done within Debian itself
(although the upcoming PPAs in Debian may solve this). Because it's so
difficult to properly integrate 3rd party repositories with the Debian
archive, all that 3rd party packaging should happen in Debian itself.
This is something pgApt understands better than other 3rd party
repositories.
>> 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 to let you do the work to support sfcgal in the packaging
for pgApt. How to best support the different use cases for the 3rd party
repositories is still a difficult issue in the Debian GIS team for which
we don't have known good solutions or best practices. I'm very happy
that you moved postgis to the team, and that I can focus on the
integration with the rest of our packages, and you take care of the
pgApt side. In the same fashion I'm very happy with Johan's work on the
Ubuntu side, I don't have to worry about that too.
>> 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.
pgApt is what other 3rd party repositories should look at how to manage
packages outside the Debian archive. Don't get me wrong, I'm no hater of
pgApt or something, I dislike (the need for) 3rd party repositories in
general and gladly acknowledge that pgApt is one of the best managed 3rd
party repositories. It's close relation to Debian and upstreaming the
work needed to support pgApt are some of the things it gets right.
>> 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.
Yes, that's a strong argument in favor of not regressing on the sfgcal
support in pgApt.
> 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.
pgApt also supports Ubuntu directly.
My focus is on Debian where I'm able to address the packaging issues at
the source, and have the derivatives pick it up from there.
I was not happy that a lot of the packaging work had moved to the
UbuntuGIS PPA when development in Debian got stale. It's very
understandable for all those Ubuntu users, but it didn't benefit the
wider Debian-based ecosystem because those changes weren't upstreamed
back to Debian.
The slow Debian development is no longer an issue (until I get hit by a
bus), and the divergence of UbuntuGIS vs Debian is also a solved problem
now thanks to Johan. We still need more people to co-maintain our
packages to address the bus factor, but I'm pretty happy about the way
thing are going now.
> 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 don't reject pgApt, I just classify as any other 3rd party repository
that maintains packages outside of the Debian archive. And as mentioned
above I like it as one of the best managed 3rd party repositories.
When pgApt gets reimplemented using the Debian PPAs I won't be reluctant
to maintain postgis there to. It won't be a 3rd party repository
anymore, the Debian PPAs are properly integrated in the archive.
>> 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.)
If you can make the template solution work in the existing branches, I'm
happy to keep using that. I don't want to obstruct the work for pgApt
either. I just hope we can find a solution with which we're both happy.
>> 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.
The OR-ed build dependencies are also useful for the official Debian
backports those don't bother me much, I do prefer to change the
dependency in the backports branch to let the master branch focus on sid.
> 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).
Thanks for your continued work on pgApt side. I like having an active
co-maintainer to address some of the bus factor.
> 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.
I'd also like to keep working together, that's why I brought this thread
to your attention. I want your input how to support sfgcal in pgApt too
since we can't rely on alternative dependencies like we do for
backports. I hope we can do with less arguments in the future though.
Let our work speak for us.
> Is that proposed path of action acceptable to you?
Yes, please commit what you need to support sfcgal for pgApt too. I
leave the pgApt side entirely up to you.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: