Re: Fwd: Bug#958047: RFS: mercantile/1.0-1 [ITP] -- python3-mercantile - Web mercator XYZ tile utilities
- To: debian-gis@lists.debian.org
- Subject: Re: Fwd: Bug#958047: RFS: mercantile/1.0-1 [ITP] -- python3-mercantile - Web mercator XYZ tile utilities
- From: Joachim Langenbach <joachim.langenbach@engsas.de>
- Date: Sun, 03 May 2020 11:39:05 +0200
- Message-id: <[🔎] 6159569.gvAq5KphkC@desktopjo>
- In-reply-to: <057fde23-d105-9da3-15f0-5d076b4865c5@xs4all.nl>
- References: <1986637.CZDv8jylmg@desktopjo> <b7d812b8-964d-3120-812a-4b367d36d026@xs4all.nl> <057fde23-d105-9da3-15f0-5d076b4865c5@xs4all.nl>
Hello Bas,
many thanks for your fast, detailed review. It is very appriecated, also I
haven't found the time to fix all issues until now. But now I have uploaded a
the version 1.1.4-1 to mentors.
> debian/changelog:
>
> Have a look at this changelog for example, that's what a typical first
> entry looks like (only the 'Initial release' change):
>
> https://salsa.debian.org/debian-gis-team/python-stetl/-/blob/debian/1.0.8+ds
> -1/debian/changelog
I wasn't aware, that I could upload a -x version again to mentors, so I
incremented it. But I removed it now.
>
> debian/control:
>
> Restructure the file with `cme` as documented in the policy:
>
> https://debian-gis-team.pages.debian.net/policy/policy.html#cme
cme fix does not change a thing. Do I miss something?
> Using both debhelper (>=10) & debhelper-compat (=12) defeats the
> purpose of debhelper-compat, use only that. See for example:
Fixed
>
> https://salsa.debian.org/debian-gis-team/pydecorate/-/blob/debian/0.3.1-1/de
> bian/control
>
> Note that using compat 12 complicates backports to Ubuntu LTS releases
> which the UbuntuGIS project does, as documented in the policy:
>
> https://debian-gis-team.pages.debian.net/policy/policy.html#debian-compat
Reverted to 10
>
> The markdown syntax in the extended description is not used by most
> consumers of this data, it should just be plain text.
>
> Relevant policy section:
>
>
> https://www.debian.org/doc/debian-policy/ch-binary.html#the-description-of-a
> -package
>
> The Documentation paragraph and the See .. for more paragraph are not
> appropriate for an extended description.
>
Fixed
>
> debian/copyright:
>
> While `licensecheck --deb-machine -r *` doesn't report the copyright
> years, LICENSE.txt does and those are missing for Sean Gillies.
>
> The usual syntax for the Copyright field is:
>
> Copyright: <year-year>, <author>
> <year>, <other author>
>
> Notice the comma between the copyright years and copyright holder.
>
> The copyright documented docs/conf.py is also missing.
May you explain this a little bit? I didn't understand that.
>
> The © symbol in copyright statements is useless, the field name
> Copyright is sufficient.
>
Done
>
> debian/patches/0001-removed-coveralls-from-test-requirements.patch
>
> The changelog entry from the patch description should be removed.
>
> The patch should also be marked as Forwarded: not-needed as documented
> in DEP3:
>
> https://dep-team.pages.debian.net/deps/dep3/
Done
>
> debian/python3-mercantile.lintian-overrides:
>
> Overrides without comments explaining why the override was added are
> bad.
>
> Instead of the library-package-name-for-application override, add a
> mercantile binary package to include usr/bin, and have it depend on
> python3-mercantile, see for example:
>
>
> https://salsa.debian.org/debian-gis-team/python-stetl/-/blob/debian/2.0+ds-2
> /debian/rules#L41
>
> https://salsa.debian.org/debian-gis-team/python-stetl/-/blob/debian/2.0+ds-2
> /debian/control#L57
>
> Don't override wrong-section-according-to-package-name, either change
> the section for the source package, or just for the binary package.
>
> The above example uses "science" for the source package, "python" for
> the python3-stetl binary package, and "utils" for the stetl binary
> package.
Done
>
> Either add a comment for the embedded-javascript-library overrides
> explaining why the libjs packages aren't suitable, or drop the override
> and use the packaged versions.
>
> The python-stetl package does the latter, you can see the dependencies
> in debian/control and symlinks are used to use the packaged JS files:
>
>
> https://salsa.debian.org/debian-gis-team/python-stetl/-/blob/debian/2.0+ds-2
> /debian/links
>
Cool. Done it with links.
>
> debian/rules:
>
> Put an empty line before the %: line.
>
> Grouping all pybuild options in exported environment variables is
> preferred, so replace --test-pytest with export PYBUILD_TEST_PYTEST=1.
> See for example:
>
>
> https://salsa.debian.org/debian-gis-team/python-pyproj/-/blob/debian/2.6.0+d
> s-1/debian/rules
>
> Since the package is Architecture: all using
> override_dh_auto_build-indep is not required, just
> override_dh_auto_build is sufficient.
>
> Using an -arch or -indep override without also using the appropriate
> option for the relevant dh_auto_* command is wrong.
>
> Building the docs should be done after dh_auto_build.
>
> The dh_link override and jdupes build dependency can be dropped,
> removing duplicates is not worth it for such a small package. It's also
> an unneeded diversion from upstream.
>
Done
>
> debian/source/options:
>
> Don't ignore build artifacts, ensure that they are removed in the clean
> target.
>
Done
>
> debian/upstream/metadata:
>
> Drop the Changelog field, https://github.com/mapbox/mercantile/releases
> is not a changelog. Upstream doesn't provide an annotated changelog
> like QGIS does for example, so the field in upstream metadata has no
> added value.
>
> Add the Bug-Submit field, see for example:
>
> https://salsa.debian.org/debian-gis-team/python-stetl/-/blob/master/debian/u
> pstream/metadata
>
> Also drop the Documentation field, it has no added value to the
> documentation already included in the package.
>
Done
>
> debian/watch:
>
> Handle common issues by adding dversionmangle & uversionmangle:
>
> https://wiki.debian.org/debian/watch#Common_mistakes
>
> See for example:
>
> https://salsa.debian.org/debian-gis-team/fiona/-/blob/master/debian/watch
Done. By the way: The fiona team is using upstream releases instead of tags as
I do. If I'm thinking about it, I may should switch to releases to. Is there a
common understanding about that? Or depends it on the behaviour of the
upstream team?
Regards,
Joachim
Reply to: