Date: Tue, 4 Sep 2007 15:18:51 -0700 (PDT) From: Doug Barton <dougb@FreeBSD.org> To: Michael Nottebrock <lofi@freebsd.org> Cc: cvs-ports@freebsd.org, cvs-all@freebsd.org, linimon@freebsd.org, Roman Bogorodskiy <novel@freebsd.org>, ports-committers@freebsd.org Subject: Re: cvs commit: ports/security/gnupg Makefile Message-ID: <alpine.BSF.0.9999.0709041513570.2430@ync.qbhto.arg> In-Reply-To: <46DD46EB.2020605@freebsd.org> References: <200709021108.l82B8Axp085777@repoman.freebsd.org> <alpine.BSF.0.9999.0709021304590.54479@ync.qbhto.arg> <20070903051037.GA27386@underworld.novel.ru> <alpine.BSF.0.9999.0709031352120.31928@ync.qbhto.arg> <46DD46EB.2020605@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Sep 2007, Michael Nottebrock wrote:
> Doug Barton schrieb:
>>>
>>> OPTIONS would be reasonable in this case. We can enable ncurses backend
>>> by default and user will be able to configure the port to make it use
>>> other backends he/she wants.
>>
>> That is basically what I had in mind. I'd like to hear from lofi, but
>> my offer to help with that is still good.
> Security/pinentry is an "old school" master-port for the
> pinentry-[toolkit] slave-ports. I stopped doing master-slave ports of
> that sort after that one precisely because you end up in situations like
> this where people manage to miss the ports they are supposed to use
> despite the fact they are being pointed to them in pkg-messages and they
> can be very easily found in a search.
So it sounds to me like you're saying that the pinentry port is not
designed to be used directly?
> Apparently even committers sometimes cannot see the wood for the trees
> because Roman could have just added options for each of the pinentry
> slave ports to the already existing gnupg options menu in his PR
> instead.
That's an interesting idea that I hadn't considered. I think doing that,
with a default of the curses version would probably be ok ... the only
concern I have with that is what to do if the user chooses more than one
and they conflict. Generate a fatal error?
> I would like that better than a runtime dependency on an
> option-ifyed pinentry port, but not by much, because the main reason why
> I never added a runtime dependency on any pinentry to the gnupg port
> (back when it was still gnupg-devel) still remains: Whatever pinentry
> you depend on by default through whatever indirection, it will be always
> be the wrong one for the package users out there. That is why the
> pkg-message in gnupg exists.
Well as I said at the start, I agree with this approach, but if others are
determined to add a dependency, I think doing it in a less painful way is
a good idea.
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.0.9999.0709041513570.2430>