Date: Fri, 06 Feb 2015 20:40:18 +0000
From: bugzilla-noreply@freebsd.org
To: freebsd-ports-bugs@FreeBSD.org
Subject: [Bug 195426] mail/pine-pgp-filters Makefile contains incomplete check for ${LOCALBASE}/bin/gpg2
Message-ID: <bug-195426-13-0haVqQ3U4I@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-195426-13@https.bugs.freebsd.org/bugzilla/>
References: <bug-195426-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195426 --- Comment #8 from John Marino <marino@FreeBSD.org> --- (In reply to Trond.Endrestol from comment #7) > Maybe dougb@ should be consulted on the matter. I see no reason to do that. > Regardless of the fact of whether security/gnupg and security/gnupg1 can > coexist, why install security/gnupg1 if security/gnupg is already on the > system? You seem not to be aware of how the builders work. By definition, nothing is installed on the system, ever, before the target port is built. For binary packages, which are the primary concern these days, this is a case that can never happen unless somehow the dependencies pull in both of them Secondly, who cares? We don't want to stick with an inferior version just because it's already installed on the system. You want the most appropriate version for pine. They range from 1.0M-1.5M in package size anyway, it a trivial amount of resources to have both. > The same argument can be made for security/gnupg1 when security/gnupg is > missing. The problem is I don't see any argument at all. > I just wanted to fix what was intended in the Makefile. ${LOCALBASE} would > normally expand to /usr/local, thus ${LOCALBASE}/bin/gpg2 would become > /usr/local/bin/gpg2. Without my patch from November, ${LOCALBASE} remains > empty, and the condition in the Makefile can never be satisfied. What was intended is dubious at best. I think it needs to be removed entirely. As I said, for the package builders it doesn't even work. It only comes into play for people building on live systems (something I recommend against doing) and even then, the logic becomes: If the inferior version is installed on your system, use that instead of what you should use. I really don't see how this is a good thing. The argument seems to be to avoid building or installing a single rather small dependency. It's not even worth the complexity. It's good you brought this up so it can be removed IMO. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-195426-13-0haVqQ3U4I>