On Sat, 28 Nov 2020 12:42:34 +1300, Andrew Ruthven wrote:
> > > * add missing debian/upstream/metadata
> I've created as much of this as I can.
> Also, could dh-make-perl generate some of the contents of this file?
It does, but only if upstream provides the data :)
(And basically we use debian/upstream/metadata only for the upstream
Git repo. But looking at the file you created taught me some new keys
I haven't seen before :))
dpt-debian-upstream also creates debian/upstream/metadata (but again
only if the information is in META.{yml,json}). Oh, and lintian-brush
as well (not sure where it looks).
> > Also : "X: perl-module-name-not-mentioned-in-description
> > Module::Install::Substitute"
> Fixed.
This lintian tag is more about the long description in debian/control,
and not about the upstream POD. - Unsurprisingly, lintian still
finds:
X: libmodule-install-substitute-perl: perl-module-name-not-mentioned-in-description Module::Install::Substitute
And then (re your other patch) lintian now also tells us:
P: libmodule-install-substitute-perl source: spelling-error-in-patch-description debian/patches/add-name-to-description.diff grammer grammar
> > The actual problem I'm seeing is that we don't have any copyright
> > statement in the whole code. I mean there is section titled
> > "COPYRIGHT" in the README but it doesn't talk about (a) copyright
> > holder but about the license.
> >
> > Well, the Berne Convention to the rescue which allows us to assume
> > that the author is the copyright holder. Cf.
> > https://perl-team.pages.debian.net/copyright.html#Berne_Convention
>
> Yes, I had made an assumption that the author would hold the copyright,
> and that is what dh-make-perl assumes as well as it generated the block
> in debian/copyright.
Right, totally fine.
> > So I would write:
> > Files: * […]
> Done.
Great.
> Perhaps this is something that dh-make-perl can insert in these
> circumstances as well?
That's a bit hard to do [0] but if you have ideas: you have the commit
bit for dh-make-perl as well :)
> > (I tend to put no years there as upstream doesn't tell us anything
> > about the period, and IMO it's not our job to second-guess them. But
> > I'm also fine if someone deduces the years from the changelog or
> > commit dates or whatever.)
> I had looked at the Changes file to determine the copyright years. I am
> happy to remove the year ranges if that is preferred.
Feel free to keep them if you prefer it this way.
> > Also interesting is that Andrew put his work under GPL-2+. That's of
> > course fine as a personal preference; we usually pick a superset of
> > $upstream_license and $same_as_perl for debian/* (which is just
> > $same_as_perl here and in most cases). - One reason why GPL-2+ might
> > be problematic is that it leads to potential patches under a
> > different license than what upstream uses …
> My default license is GPL-2+. However, I see your point about patches
> etc, so I have re-licensed it to $same_as_perl. I will make the same
> change to some other Perl modules I'm working on as well.
Ok, great.
Cheers,
gregor
[0]
Especially copyright/license stuff is difficult to get right, and
needs manual inspection anyway. And detecting that a README talks
about a COPYRIGHT which is not a copyright statement but a license and
that there's an AUTHOR who probably is also the copyright holder …
would be too high an expactation from a poor little perl script like
dh-make-perl IMO.
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: The Cranberries: Daffodil Lament
Attachment:
signature.asc
Description: Digital Signature