stray file on buildbot machine

Ryan Schmidt ryandesign at macports.org
Fri Sep 9 13:32:47 PDT 2011


On Sep 9, 2011, at 05:30, Markus W. Weißmann wrote:

> 
> On 9 Sep 2011, at 11:16, Ryan Schmidt wrote:
> 
>> On Sep 8, 2011, at 15:39, Markus W. Weißmann wrote:
>>> ...
>>> I'm not sure how to fix this for any build, but could you just delete /opt/local/bin/scheme48-config on the buildbot machine for now?
>> 
>> This does need to be fixed in the portfile. It's not just a stray file on the build machine; it's a stray file on any user's machine who has installed this port, and an activation failure when they try to upgrade to the fixed version:
>> ...
>> Examples of how this was fixed in other ports can be found in r83569 and r46351.
>> 
> 
> I think this behavior is extremely dangerous -- deleting files you think you left behind yourself and hope don't belong to another port or whatever.

I think it's fairly safe to assume that /opt/local/bin/scheme48-config came from the scheme48 port.

If there had been a scheme48-devel port, and you were worried that the file might belong to that port, then that would not be a problem, because scheme48 and scheme48-devel would have been marked as conflicting with one another, which would have prevented MacPorts from even trying the activate phase of the one while the other was active. And you only do the deletions of the offending files in pre-activate.

Yes I don't really like this solution either but it's the best I know of for now. I mean the best idea is to not install files outside of the destroot in the first place, but obviously we don't intend to do it, so when we discover that it has happened, we need to clean it up as best we can.

> I hope trace mode will prevent this from happening?

Trace mode was extremely broken for me the last time I tried to use it a couple years ago, basically preventing most ports from installing, so I haven't tried it since.




More information about the macports-dev mailing list