Date: Fri, 30 May 2014 15:00:55 -0400 From: Lowell Gilbert <freebsd-ports-local@be-well.ilk.org> To: "Matthew D. Fuller" <fullermd@over-yonder.net> Cc: ports@freebsd.org, Robert Huff <roberthuff@rcn.com> Subject: Re: second call: dns/libidn staging broken Message-ID: <44mwdzdrbs.fsf@be-well.ilk.org> In-Reply-To: <20140530021204.GC33666@over-yonder.net> (Matthew D. Fuller's message of "Thu, 29 May 2014 21:12:04 -0500") References: <53864C62.2020507@rcn.com> <44egzdv1y2.fsf@lowell-desk.lan> <448upluwa5.fsf@lowell-desk.lan> <20140530021204.GC33666@over-yonder.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"Matthew D. Fuller" <fullermd@over-yonder.net> writes: > On Wed, May 28, 2014 at 10:57:22PM -0400 I heard the voice of > Lowell Gilbert, and lo! it spake thus: >> >> Assuming my previous paragraph isn't wildly wrong, the easy >> workaround would be to install emacs. That's just a hack; the right >> fix (I think) is to add a port option to let it depend on emacs, or >> for the port to adjust the plist dynamically. > > That doesn't sound right. I don't have emacs installed, and > > % ls `pkg info -l libidn | grep \.el` > /usr/local/share/emacs/site-lisp/idna.el > /usr/local/share/emacs/site-lisp/punycode.el > > So I'd keep looking for the reason. If this is a pre-staging libidn install (possible: the version and revision info haven't changed since before that) then it makes my theory more likely. Otherwise, it certainly means that requiring emacs isn't a proper fix, but if I'd been thinking clearly I would've realized that didn't make sense anyway, because there are so many variants of emacs. Which is exactly why the libidn configure script is so complicated in its attempts to find the install location for those elisp files. Also, it seems to build okay on the package cluster under poudriere, so the lack of emacs clearly isn't a general problem for the port. Nonetheless, the specific error messages indicate that those elisp files weren't copied into the staging area. I'm pretty sure from my analysis of the configure script that this would only happen if it couldn't find an emacs-like program to interrogate for the elisp load path, or if it did find one and got a different load path than the one in the plist.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44mwdzdrbs.fsf>