Re: Newbie questions on packaging opencpn
Hi Alec,
On 9/2/18 5:38 PM, Alec Leamas wrote:
> Thanks for taking time to review. I figured the first package would be a
> bumpy road, and indeed it is. Here are lot's of new tools and practises
> for me...
Yes, but once you get the hang of the tools, packaging becomes quite easy.
Make sure that you configure the lintian hook and always build your
packages in a cowbuilder chroot, as documented in the policy, this
points out many issues with packages. See:
https://debian-gis-team.pages.debian.net/policy/packaging.html#git-pbuilder
You should also look at how other packages in the team do things.
https://codesearch.debian.net/ is a good resource to find how other
packages in- and outside the team do things.
> On 01/09/18 09:58, Sebastiaan Couwenberg wrote:
>> On 9/1/18 9:17 AM, Alec Leamas wrote:
>> * debian/compat
>>
>> Consider using debhelper compatibility level 9 instead, it allows for
>> easier backports to Debian stable and Ubuntu LTS releases.
>
> Ok... doesn't seem to break anything (?)
It won't break, you just need to account for the new defaults in compat
11, like you did with the --parallel dh option.
See the COMPATIBILITY LEVELS section in the debhelper(7) manpage for
details of the changes.
Note that the version requirement of the debhelper build dependency
needs to match the compat level to enable backports with debhelper 9.
sed -i 's/debhelper (>= 11)/debhelper (>= 9)/g' debian/control
>> Maintainer must be the Debian GIS Project, and you should be in the
>> Uploaders field.
>
> Done
The value of the Maintainer field is still wrong, see:
https://debian-gis-team.pages.debian.net/policy/policy.html#debian-control
Your email address is not consistent, in the changelog you use
@gmail.com and in the control file @googlemail.com. Note that the former
should be used, because there is no DMARC configuration for the
googlemail.com domain with gets mails sent from that domain marked as spam.
Set the DEBFULLNAME & DEBEMAIL variables in your environment to have the
packaging tools use the correct name & email address by default. See:
https://debian-gis-team.pages.debian.net/policy/packaging.html#git-options-devscripts
And:
https://manpages.debian.org/stretch/devscripts/devscripts.1.en.html
>> The Vcs-* fields must point to the repository on Salsa.
>>
>> Use cme to restructure of the control file, see:
>
> Done
The value of the Vcs-Browser field is invalid:
sed -i 's/§$//' debian/control
Also, why did you change the Section from libs to misc?
libs appropriate for the source package too, if you want to source
package in misc, then the binary package for the shared library needs
the "Section: libs" field.
Also, both the binary package names need to be prefixed with 'lib':
sed -i 's/Package: /&lib/g' debian/control
sed -i 's/Depends: unarr1/Depends: libunarr1/g' debian/control
And the .install files renamed accordingly.
See:
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
The package description for the -dev package is too short, it should
include the same general description as the library and an additional
line to distinguish the shared library & development package.
>> https://debian-gis-team.pages.debian.net/policy/policy.html#debian-control
>>
>> * debian/copyright
>>
>> Has syntax errors.
>>
>> Strip the ./ from the file paths.
>
> Fixed using cme (new tool for me, seems nice).
Please remove the .git suffix from the Source URL, as that's what web
browsers use.
The first Files section can be simplified to:
Files: *
With captures the license & copyright for all files.
Any files that have a different license then get their own Files paragraphs.
The Copyright field for the first Files section also has a syntax error.
You should also remove the "Otherwise" section from the GPL-2+ license
paragraph, referring to the packaged license is sufficient.
>> The license paragraph for LGPL-3 doesn't include the standard content,
>> hence it's not known if it's the "or later" version. See for example:
>
> Updated (it's plain LGPL-3, not LGPL-3+)
The LGPL-3 license paragraph also needs to refer to the packaged
license, since it doesn't include the full text of the license.
>> https://debian-gis-team.pages.debian.net/policy/policy.html#debian-copyright
>>
>> * debian/patches
>>
>> Consider adding DEP-3 headers to indicate whether the patches have
>> been forwarded and applied upstream.
>
> Not much to tell.. but it was an important remminder to me to upstream
> relevant patches (done).
Have you configured the .quiltrc as documented in the policy? This
enforces the standard patch format, the diffstat and index lines are
useless for example.
See:
https://debian-gis-team.pages.debian.net/policy/policy.html#quilt
>> Don't specify custom commands in the dh_auto_* overrides, instead pass
>> arguments to those dh_auto_* commands.
>
> Indeed, I had bad feelings about that. Fixed.
override_dh_auto_clean is wrong, dh_clean has its own override, but you
don't need to delete the obj-* directory explicitly, dh_auto_clean
already does that.
>> * debian/README.source
>>
>> The non-standard way to download upstream tarballs is not documented
>> in this file.
>
> Fixed
You should use the common format for this file:
<Some descriptive title>
------------------------
<Various paragraphs of notes>
>> How is it decided which commit to package?
>
> Upstream has not committed anything since 2015, so the tip is sort of
> stable.
The current state requires you to keep an eye on the upstream repo for
changes, e.g. bug & security fixes.
Some additional comments.
* debian/.gitignore
This files should be removed, you should not ignore generate files in
the working directory, these should be removed by the clean target in
debian/rules.
git-buildpackage should always be run from a clean working directory to
not include cruft in the source package.
A debian/.gitignore should only be used to override settings in the
.gitignore included in the upstream source, because this usually cannot
be achieved with a quilt patch.
Kind Regards,
Bas
Reply to: