tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: libreswan 4.7 for wip



Andrew Cagney <andrew.cagney%gmail.com@localhost> writes:

>> - It's not actually in wip (did you just not push?).
>
> hmm, write access, hmm

That's not hard.  We've probably handed out access to a kiloperson just
for asking.

https://pkgsrc.org/wip/
https://pkgsrc.org/wip/users/

>> - There is no COMMIT_MSG (for use when committing the cvs add).
>
> Ah.
>
> Would it be possible for url2pkg to generate a stub for this file and
> pkglint to, er, lint it when present?
> (credit where credit is due: url2pkg did a pretty good job)

pkglint could complain if it isn't present in wip.  In pkgsrc proper it
doesn't belong (checked in).

(The point is to reduce the amount of work someone with CVS write access
has to do to import a completed package.)

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

Sure - just mentioning it since you asked for comments, and it didn't
seem ready.

> But this brings up a question.  How should I document limitations such
> as https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=56836

To first order, you don't, because that is not a bug in the package.

You could, but it really is not about the package: it applies to anyone
using libreswan on NetBSD whether they built it themselves.  So this
should be documented in some OS-specific help documentation maintained
upstream.

(The primary points of pkgsrc are to automate the build, to allow
adding/removing binary packages, and to regularize install locations.
Fixing upstream bugs and adding docs that belong upstream are
workarounds, rather than really belonging, and those changes should be
pushed upstream.)

>> - patch to mandir is not really about NetBSD so much as pkgsrc.  patch
>>   should have a patch comment, not pasted in git commit message, and if
>>   this is entirely adjusting to pkgsrc norms, an explanation that it
>>   doesn't belong upstream (in lieu of the otherwise required URL to
>>   upstream bug report or merge request).
>
> It was cherry-picked from upstream so from Libreswan's POV it is
> correct.  I'll add a PKGSRC cover note, something like "Backported
> from upstream".

The convention of /usr/pkg/man is a pkgsrc thing.  /usr/share/man is
where base man pages go.  hier(7) does not seem to specify where man
pages go in /usr/local or some other random prefix.

And, the ${PREFIX}/man convention is used with pkgsrc for every
operating system.  So this change is properly used for building on any
system with pkgsrc, not for building on NetBSD.

> 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?

There is a way to apply an upstream patch file, which is typically how
we apply patches released by upstream.

> Also, is there a way to package mainline (aka unstable) in parallel?
> Or would that mean a separate libreswan-unstable package?  Anyone
> reporting a problem to upstream libreswan will likely, eventually, be
> asked to test libreswan's mainline.

Yes, add libreswan-git and see mk/fetch/github.mk or equivalent.
Definitely it's a second package; packaging systems should primarily
package releases and if upstream recommends running from git instead
(other than for debugging as you say) that means they are overdue :-)

It is fairly typical to have a release and a git/whatever version, and
for the release version to end up in pkgsrc proper and the git one to
stay in wip.

>> Those are all minor comments of course.   Thanks for doing this; I had
>> lost track of *SWAN entirely.
>
> I suspect the files that end up in */etc still need some work.

I didn't look at that.  Beware that examples go in examples, and
CONF_FILES.  Similarly for rc.d.

My own opinion, not a pkgsrc norm, is that the config file that is
installed via CONF_FILES should be sparse, and basically the minimal
file to do something useful.  And really upstream should operate with a
tiny config file.  I think it's fine to have bigger examples that are
not installed, as true examples.  But that's just my take, not pkgsrc
policy.

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index