second call: dns/libidn staging broken

[Lowell Gilbert]

Lowell Gilbert <freebsd-ports-local at be-well.ilk.org> writes:

> Robert Huff <roberthuff at rcn.com> writes:
>
>> Kevin Oberman writes:
>>
>>> >       This port builds fine, or seems to.  However, when I try to
>>> > install I get this:
>>>
>>>  Looks like it might be an issue with your build environment. Looks
>>>  like you have customized your build directories (/data/port-work). I
>>>  suspect something might be wrong there. I have seen several reports
>>>  of issues when symlinks are used in these types of customizations.
>>
>> 	It's not a sym-link, it's an evnironment variable:
>>
>> WRKDIRPREFIX=/data/port-work
>>
>> 	This was done because certain large ports (e.g. libreoffice)
>> were eating up all the free space on /usr.  So I pointed the work
>> directory to /data, which has 200+ gbytes free.	This works fine except
>> is rare cases like this one.
>> 	So ... how do I go about further diagnosing the breakage and
>> getting that to {maintainer, pkg-ng team} who can Do the Right Thing?
>
> I've seen some funny things with WRKDIRPREFIX too, but I can't reproduce
> them. I've mostly seen it on my chroot tinderbox, which always runs with
> WRKDIRPREFIX set because the ports tree is mounted read-only. The
> tinderbox is currently broken for other reasons.
>
> I tried rebuilding libidn on the host system (outside the tinderbox),
> but it didn't break (with and without WRKDIRPREFIX, with portmaster or
> "make install"). I guess I need to fix my tinderbox to get further...

I managed to reproduce my problem in the tinderbox, but it's an issue
with a workaround for libtool version parsing, so it wouldn't affect
elisp files. 

Looking at the configure output for libidn, I'll guess that you don't
have emacs installed when you try to install libidn, so the configure
script decides not to install the elisp (.el) files, and staging chokes
because it depends more heavily on the plist than the old port system
did.  You can look at the generated config.log to see if it backs me up
on this.

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.