suggestions for url2pkg and pkglint (was: Re: libreswan 4.7 for wip)

[Roland Illig <roland.illig%gmx.de@localhost>]

Am 15.06.2022 um 17:07 schrieb Andrew Cagney:
> On Wed, 15 Jun 2022 at 05:09, Greg Troxel <gdt%lexort.com@localhost> wrote:
> > - There is no COMMIT_MSG (for use when committing the cvs add).
>
> Would it be possible for url2pkg to generate a stub for this file and
> pkglint to, er, lint it when present?

Sure. Since the pkgsrc guide doesn't lose a single word about
COMMIT_MSG, I'll have to look at existing practice instead.

What do you expect pkglint to check? What comes to mind immediately is
that the default placeholders have been replaced. Anything else?

Pkglint could also check that the text in COMMIT_MSG corresponds to
DESCR and the other package files. But if COMMIT_MSG can be generated
from the package itself, I don't see any point in having that file at all.

> (credit where credit is due: url2pkg did a pretty good job)

Thanks for the feedback, it's probably the best feedback I got for
url2pkg in the last 5 years. :)

> > - HOMEPAGE seems wrong.
>
> The contents of DESCR. which url2pkg cribbed from somewhere, are also
> wrong.  I need to find "somewhere" and get it fixed.

When url2pkg generated DESCR, it placed the following marker in line 1
of DESCR: f'TODO: Adjust the following lines from {filename}'; the
candidate filenames are 'README', 'README.txt', 'README.md' from the
extracted archive.

> > - patch to mandir is not really about NetBSD so much as pkgsrc.

Instead of the 10-lines patch, you could alternatively add the following
line to the package Makefile:

MAKE_FLAGS+=	FINALMANDIR=${LOCALBASE}/${PKGMANDIR}

> Also pkglint wanted the patch broken down into individual files.  Here
> the tweak was small so accommodating that requirement was easy but
> that isn't true in general.  What should happen when the change-set is
> more substantive?

That rule has been around for more than 20 years now, I don't know
whether it made sense at any point. For patch files that have the word
'CVE' in their name I already skip the rule, as I don't see a point in
splitting these topic-based patches.

20 years ago, the patch files were still named patch-aa, patch-ab, so
the names didn't tell anything about the purpose of the patch. At that
time, the rule may have made a bit of sense, to avoid patching a file
twice. Since several years, the filenames of patches reveal what file
they patch, making these collisions less likely.

But even if there are collisions, I don't see a problem with them. If
there are multiple patches for ./configure, the first may fix
portability issues with 'if [ $var == "value" ]', the next may fix the
location of some header files, and the third may patch the location for
manual pages.

I'm in favor of allowing per-topic patches as well. It would be up to
the package maintainer to keep the patches manageable.

> Also, is there a way to package mainline (aka unstable) in parallel?
> Or would that mean a separate libreswan-unstable package?

That's usually done via a separate package. Especially pkgsrc-wip has
many packages named '*-git'.

> I suspect the files that end up in */etc still need some work.

Yep, that's why pkglint warns about them. :)

Roland