Re: CVS commit: pkgsrc/security/gnupg21

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Mon, Sep 21, 2015 at 07:22:47PM +0900, Ryo ONODERA wrote:
> From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>, Date: Mon, 21 Sep 2015 11:47:52 +0200
> 
> > On Mon, Sep 21, 2015 at 06:30:47PM +0900, Ryo ONODERA wrote:
> >> Hi,
> >> 
> >> From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>, Date: Mon, 21 Sep 2015 11:09:41 +0200
> >> 
> >> > On Mon, Sep 21, 2015 at 09:11:42AM +0900, Ryo ONODERA wrote:
> >> >> I would like to commit these and remove security/gnupg2/buildlink3.mk
> >> >> after freeze.
> >> >> Please send me your comments.
> >> > 
> >> > Wrong package name.
> >> ???
> > 
> > It's still called gnupg, not gnupg2.
> 
> What is your 'it'?
> security/gnupg2 and security/gnupg21 share 'gnupg2' ${PKGBASE},
> because upstream says security/gnupg2 and security/gnupg21 cannot
> coexists in a environment.

Sorry, mea culpa.

> >> > The question remains -- why point source builds to
> >> > the 2.0.x version, when binary packages and bulk builds are picking up
> >> > the higher 2.1.x version instead?
> >> 
> >> I have no idea about your bulk build environment.
> >> In general, higher version/revision number is preferred in pkgsrc.
> > 
> > Yes, but for source builds you tell it to use gnupg2, not gnupg21.
> 
> You mean that behavior of security/gnupg2 and security/gnupg2 is
> not in usual way?

Bulk builds and binary packages use the list of all packages and match
against that. So if you have gnupg2-2.0.29.tgz and gnupg2-2.1.6nb2.tgz,
both matching the pattern, the one with the higher version is picked.
If you do a source build and don't have a matching package installed,
gnupg2 would be used as specified. That's inconsistent.

> >> > As we don't have tool support for
> >> > gnupg (and I don't see a good reason for wanting to have that), just use
> >> > ${PREFIX} and not find-prefix.mk.
> >> 
> >> At the moment, find-prefix.mk has less meaning.
> >> However using ${PREFIX} directly may became harmful in future.
> > 
> > For packages without builtin.mk support or custom sub-prefix, it is just
> > a left-over of package wedges. As such, it just adds noise and build
> > time.
> 
> I cannot judge whether it is just noise or not.
> If it is really noise, please note it in the pkgsrc guide.

The pkgsrc guide doesn't take about find-prefix.mk.

Joerg