Обсуждение: Re: Modern packaging for postgis

Bas,

On 10/09/2016 12:02 AM, Sebastiaan Couwenberg wrote:
> I've prepared a branch with changes to modernize the postgis packaging:
>
>  https://anonscm.debian.org/cgit/pkg-grass/postgis.git/log/?h=modern-packaging

Thanks for bringing this up again. Looks good from a first glance.
However, I just moved to a new home and am unlikely to look at it in
more detail within the next few days.

I gave this branch a spin on the pgapt Jenkins build farm.

> The goal of these changes is to bring the postgis package in line with
> the other packages maintained within the Debian GIS team.

(As a side note, I'm still wondering if Debian GIS is the right team for
a PostgreSQL extension. But modernized packaging is a good thing in any
case.)

> The control files are restructured with cme while preserving the changes
> for PGDG. The separate lines for dependencies greatly increase
> readability and gives cleaner diffs as a bonus.

Good. Agreed.

> The rules file is switched to use the dh sequencer to not need explicit
> calls to the various dh_* utilities. This added dh_perl amongst others
> for which the substitution variable was added to the -scripts package.

I'm worried about backwards-compatibility, here.

At least the current build already failed building the source package
for wheezy, trusty and precise:

dpkg-source: error: syntax error in source/debian/control at line 27:
continued value line not in field
dpkg-buildpackage: error: dpkg-source -i -I --before-build source gave
error exit status 25


> I've verified that both binary-arch & binary-indep builds still work.
> And also verified the build in a cowbuilder chroot with the PGDG
> repository enabled, but I suspect that the Jenkins build environment may
> differ somewhat.

It's hardly the build environment, but rather the fact that the package
should build from the same sources on older Debian and Ubuntu releases.

> Is there some way to do experimental builds for PGDG which won't
> automatically be published?

Yes, please ask myon@debian.org for access to that Jenkins builder.

> I'd like to merge these changes as soon as possible to get them into
> stretch, but I'd like you to confirm that they cause any adverse effects
> for PGDG as they did the first time I implemented modernized packaging
> some time ago.

Thanks.

Kind Regards

Markus Wanner

Hi Markus,

Thanks for the feedback.

On 10/10/2016 09:36 AM, Markus Wanner wrote:
> On 10/09/2016 12:02 AM, Sebastiaan Couwenberg wrote:
>> I've prepared a branch with changes to modernize the postgis packaging:
>>
>>  https://anonscm.debian.org/cgit/pkg-grass/postgis.git/log/?h=modern-packaging
>
> Thanks for bringing this up again. Looks good from a first glance.
> However, I just moved to a new home and am unlikely to look at it in
> more detail within the next few days.
>
> I gave this branch a spin on the pgapt Jenkins build farm.

Thanks, I'll have a look at the logs for postgis-source.

>> The goal of these changes is to bring the postgis package in line with
>> the other packages maintained within the Debian GIS team.
>
> (As a side note, I'm still wondering if Debian GIS is the right team for
> a PostgreSQL extension. But modernized packaging is a good thing in any
> case.)

In general, no. The PostgreSQL team is more appropriate for PostgreSQL
extensions in general.

In the case of PostGIS, pgRouting and pg_comparator, these are
appropriate in Debian GIS, especially the former two which are OSGeo
projects. PostGIS is an essential project in the GIS ecosystem, and all
its GIS related dependencies (gdal, geos, proj & sfcgal) are all
maintained by the the Debian GIS team too. This was my motivation to
move postgis to the Debian GIS team three years ago. The GIS team is the
appropriate place to integrate GIS packages in Debian.

>> The control files are restructured with cme while preserving the changes
>> for PGDG. The separate lines for dependencies greatly increase
>> readability and gives cleaner diffs as a bonus.
>
> Good. Agreed.
>
>> The rules file is switched to use the dh sequencer to not need explicit
>> calls to the various dh_* utilities. This added dh_perl amongst others
>> for which the substitution variable was added to the -scripts package.
>
> I'm worried about backwards-compatibility, here.
>
> At least the current build already failed building the source package
> for wheezy, trusty and precise:
>
> dpkg-source: error: syntax error in source/debian/control at line 27:
> continued value line not in field
> dpkg-buildpackage: error: dpkg-source -i -I --before-build source gave
> error exit status 25

This is indeed something that needs to be fixed, as postgis-binaries
built successfully on these distributions before.

>> I've verified that both binary-arch & binary-indep builds still work.
>> And also verified the build in a cowbuilder chroot with the PGDG
>> repository enabled, but I suspect that the Jenkins build environment may
>> differ somewhat.
>
> It's hardly the build environment, but rather the fact that the package
> should build from the same sources on older Debian and Ubuntu releases.
>
>> Is there some way to do experimental builds for PGDG which won't
>> automatically be published?
>
> Yes, please ask myon@debian.org for access to that Jenkins builder.

Since Jenkins now uses SSO I can at least access the web interface which
was not possible before. I don't really need to upload to PGDG.

>> I'd like to merge these changes as soon as possible to get them into
>> stretch, but I'd like you to confirm that they cause any adverse effects
>> for PGDG as they did the first time I implemented modernized packaging
>> some time ago.
>
> Thanks.

As said, I'll have a look at the failures on the older distributions,
those should be fixed.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

On 10/10/2016 10:13 AM, Sebastiaan Couwenberg wrote:
> On 10/10/2016 09:36 AM, Markus Wanner wrote:
>> On 10/09/2016 12:02 AM, Sebastiaan Couwenberg wrote:
>>> I've prepared a branch with changes to modernize the postgis packaging:
>>>
>>>  https://anonscm.debian.org/cgit/pkg-grass/postgis.git/log/?h=modern-packaging
>> [...]
>>> The rules file is switched to use the dh sequencer to not need explicit
>>> calls to the various dh_* utilities. This added dh_perl amongst others
>>> for which the substitution variable was added to the -scripts package.
>>
>> I'm worried about backwards-compatibility, here.
>>
>> At least the current build already failed building the source package
>> for wheezy, trusty and precise:
>>
>> dpkg-source: error: syntax error in source/debian/control at line 27:
>> continued value line not in field
>> dpkg-buildpackage: error: dpkg-source -i -I --before-build source gave
>> error exit status 25
>
> This is indeed something that needs to be fixed, as postgis-binaries
> built successfully on these distributions before.

The generate-pgdg-source script in pgapt doesn't handle the restructured
control file yet, it creates an invalid control file when it strips the
libsfcgal-dev dependency for the old distributions that don't have sfcgal.

The attached patch fixes generate-pgdg-source to handle the restructured
control file correctly.

Christoph, can you apply the patch in pgapt.git?

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Sebastiaan Couwenberg 2016-10-10 <2650902b-53d7-6361-f675-c4b012cdf98b@xs4all.nl>
> The generate-pgdg-source script in pgapt doesn't handle the restructured
> control file yet, it creates an invalid control file when it strips the
> libsfcgal-dev dependency for the old distributions that don't have sfcgal.
>
> The attached patch fixes generate-pgdg-source to handle the restructured
> control file correctly.
>
> Christoph, can you apply the patch in pgapt.git?

Hi Bas,

thanks! I just pushed a simplified version that just does
/libsfcgal-dev/d.

Christoph

Hi Christoph,

On 10/10/2016 11:45 AM, Christoph Berg wrote:
> Re: Sebastiaan Couwenberg 2016-10-10 <2650902b-53d7-6361-f675-c4b012cdf98b@xs4all.nl>
>> The generate-pgdg-source script in pgapt doesn't handle the restructured
>> control file yet, it creates an invalid control file when it strips the
>> libsfcgal-dev dependency for the old distributions that don't have sfcgal.
>>
>> The attached patch fixes generate-pgdg-source to handle the restructured
>> control file correctly.
>>
>> Christoph, can you apply the patch in pgapt.git?
>
> thanks! I just pushed a simplified version that just does
> /libsfcgal-dev/d.

Thank for the change in pgapt. The only downside to your version is that
the old format currently in use is no longer supported, and causes the
removal of the libjson build dependencies too.

If no new builds of the old packaging will be done this is not a
problem, otherwise my patch is preferred which supports both formats
(but will need improvement when the architecture restriction is removed).

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Sebastiaan Couwenberg 2016-10-10 <672ab2c9-0025-b062-6f28-9452bcf6df47@xs4all.nl>
> > thanks! I just pushed a simplified version that just does
> > /libsfcgal-dev/d.
>
> Thank for the change in pgapt. The only downside to your version is that
> the old format currently in use is no longer supported, and causes the
> removal of the libjson build dependencies too.
>
> If no new builds of the old packaging will be done this is not a
> problem, otherwise my patch is preferred which supports both formats
> (but will need improvement when the architecture restriction is removed).

The idea was that I'm only supporting the new layout, yes.
Avoiding to collect old warts is a good thing I think :)

Christoph

On 10/10/2016 12:04 PM, Christoph Berg wrote:
> Re: Sebastiaan Couwenberg 2016-10-10 <672ab2c9-0025-b062-6f28-9452bcf6df47@xs4all.nl>
>>> thanks! I just pushed a simplified version that just does
>>> /libsfcgal-dev/d.
>>
>> Thank for the change in pgapt. The only downside to your version is that
>> the old format currently in use is no longer supported, and causes the
>> removal of the libjson build dependencies too.
>>
>> If no new builds of the old packaging will be done this is not a
>> problem, otherwise my patch is preferred which supports both formats
>> (but will need improvement when the architecture restriction is removed).
>
> The idea was that I'm only supporting the new layout, yes.
> Avoiding to collect old warts is a good thing I think :)

Agreed.

All we need now is for the failed postgis-source builds to be retried to
verify that no other issues remain. Can you trigger the rebuilds?

I'll merge the changes from the modern-packaging branch into master
after the PGDG builds are all OK.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Sebastiaan Couwenberg 2016-10-10 <ca37f40a-a478-25ae-c6bd-dad5b7a612ff@xs4all.nl>
> All we need now is for the failed postgis-source builds to be retried to
> verify that no other issues remain. Can you trigger the rebuilds?
>
> I'll merge the changes from the modern-packaging branch into master
> after the PGDG builds are all OK.

Hi Bas,

I rebuilt postgis in jenkins and the builds succeeded. (I didn't do
any further checks, though, maybe Markus might want to inspect the
results?)

Thanks!
Christoph

On 10/10/2016 12:08 PM, Sebastiaan Couwenberg wrote:
> On 10/10/2016 12:04 PM, Christoph Berg wrote:
>> Re: Sebastiaan Couwenberg 2016-10-10 <672ab2c9-0025-b062-6f28-9452bcf6df47@xs4all.nl>
>>>> thanks! I just pushed a simplified version that just does
>>>> /libsfcgal-dev/d.
>>>
>>> Thank for the change in pgapt. The only downside to your version is that
>>> the old format currently in use is no longer supported, and causes the
>>> removal of the libjson build dependencies too.
>>>
>>> If no new builds of the old packaging will be done this is not a
>>> problem, otherwise my patch is preferred which supports both formats
>>> (but will need improvement when the architecture restriction is removed).
>>
>> The idea was that I'm only supporting the new layout, yes.
>> Avoiding to collect old warts is a good thing I think :)
>
> Agreed.
>
> All we need now is for the failed postgis-source builds to be retried to
> verify that no other issues remain. Can you trigger the rebuilds?
>
> I'll merge the changes from the modern-packaging branch into master
> after the PGDG builds are all OK.

Since the PGDG builds are now fixed, I've merged the changes into master
and prepared a new upload to unstable.

Thanks for Markus and Christoph for their work on the PGDG side!

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1