Обсуждение: 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