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. > > 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. 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. > > So, do what you reckon is best, but I do not think that > security/pinentry needs to be changed.
Eh... sorry, I don't consider configuring one port using OPTIONS of _other_ port is a sane way of doing things, it's even worse than handling dependencies using pkg-message. However, I'm not going to take part in this discussion anymore, you're free to do what you want, and I'm not even a maintainer of gnupg. KTHX Roman Bogorodskiy
pgpXypIMNCgLs.pgp
Description: PGP signature
