ports/158179: some packages do not fully honor -P dir option in pkg_add(1)

[Chris Rees]

On 16 Jul 2011 17:18, "Stephen Montgomery-Smith" <stephen at missouri.edu>
wrote:
>
> current@ to ports@ again.  (Sorry, my mistake.)
>
>
> On 07/16/2011 11:10 AM, Chris Rees wrote:
>>
>>
>> On 16 Jul 2011 17:04, "Stephen Montgomery-Smith" <stephen at missouri.edu
>> <mailto:stephen at missouri.edu>> wrote:
>>  >
>>  > On 07/16/2011 10:53 AM, Chris Rees wrote:
>>  >>
>>  >>
>>  >> On 16 Jul 2011 16:38, "Stephen Montgomery-Smith"
>> <stephen at missouri.edu <mailto:stephen at missouri.edu>
>>  >> <mailto:stephen at missouri.edu <mailto:stephen at missouri.edu>>> wrote:
>>  >> > For example, suppose the C source code contains something like:
>>  >> > char applications_dir = "/usr/local/share/applications";
>>  >> > and this is filled in by the ./configure script.
>>  >> >
>>  >> > How is that handled?
>>  >> >
>>  >>
>>  >> It's not.
>>  >>
>>  >> Remember what a package is, literally the files from the plist tarred
>>  >> with some magic +FILEs and the pkg-*install files- if paths are
>>  >> hardcoded in objects that's how it'll be installed.
>>  >
>>  >
>>  > What if some of the installation programs are binaries, and
>> "/usr/local" is hard coded into installation binaries or scripts
>> provided by the software itself.
>>
>> Sorry, poor wording on my part.
>
>
> No, I didn't read what you said properly.
>
>
>> If it was compiled as prefix=/usr/local, that's how it'll be installed,
>> regardless of your -p argument.
>
>
> So "-p" and "-P" are inherently buggy, and should be removed from pkg_add?
>
> (Or every port which uses prefix=/usr/local needs major revision and
patching, which I think is an intolerable workload.)

They are only for internal and experimental use really anyway. Perhaps the
manpage should mention that.

Bear in mind they should work fine if the port doesn't hardcode absolute
paths.

Chris