Using an older port to make another port

Michael keybounce at gmail.com
Sun Mar 5 00:58:13 UTC 2017


On 2017-03-04, at 4:44 PM, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote:

> You could just locally revert the offensive change to libarchive until your issue is addressed.

Ok, how?

Is it as simple as "copy these files out of the git tree into the /opt tree"? And if so, will that "clean up" automatically the next time I do a selfupdate?

Is there an environment variable I can set to say "Find the portfiles here, rather than in the default location"? My concern here is that I can easily think of cases where turning back a library requires turning back the programs that use that library.

> 
> --Jeremy
> 
>> On Mar 4, 2017, at 13:18, Michael <keybounce at gmail.com> wrote:
>> 
>> How do I use an older port when making another one?
>> 
>> I followed the instructions for working with an older version of libarchive.
>> Going back to 97887a375da5d0f6abee018b145833aa02e2bda7 gave me libarchive @3.2.2_1 as a pre-built binary, no problems.
>> 
>> Now I'm trying to build cmake, which wants libarchive. I've got my git clone at the same (unchanged) checkout, but attempting to install it wants to rebuild libarchive.
>> 
>> In other words, the version of libarchive currently installed matches the version at 97887, but building cmake at 97887 ("sudo port install", from the devel/cmake directory) wants to build a fresh libarchive (apparently using the system install port tree).
>> 
>> How do I make this work?
>> And how do I then fix anything else that expects a cmake? (as it will probably try to use the system definition of cmake, which will use the system definition of libarchive, which will break).
>> 
>> ---
>> Entertaining minecraft videos
>> http://YouTube.com/keybounce
>> 
> 

---
Entertaining minecraft videos
http://YouTube.com/keybounce



More information about the macports-users mailing list