Buildbot cruft: /opt/local/bin/mvn31

[Ryan Schmidt]

On Mar 18, 2015, at 1:30 AM, Mojca Miklavec wrote:
> 
> On Wed, Mar 18, 2015 at 7:09 AM, Ryan Schmidt wrote:
>> On Mar 17, 2015, at 3:24 PM, Blair Zajac wrote:
>>> 
>>> Funny, I found this code in the maven3 port because of this bug:
>>> 
>>> pre-activate {
>>>   # Remove stray files on Mavericks buildbot
>>>   foreach file {bin/mvn3} {
>>>       set filepath ${prefix}/${file}
>>>       if {[file exists ${filepath}] && [registry_file_registered ${filepath}] == "0"} {
>>>           delete ${filepath}
>>>       }
>>>   }
>>> }
>>> 
>>> I’ll put this in maven31 for an hour and then remove it.
>> 
>> If these crufty files are present on the buildbot builders, then they are probably also present on the system of any user who installed the port.
> 
> No, not necessarily. The files could also be present because of a
> failure on the buildbot (if the build was broken in the middle of
> activation step for example, so that files ended up on the system, but
> they were never registered).
> 
> I'm not saying this is the case here, but it often is.

We know that's not the case here. We know the problem was caused by a line in the destroot block that copied a file directly into prefix, bypassing destroot. This was fixed in r134042 but anybody who installed the port before that will experience an activation error when upgrading to any newer version. A fix for the activation error was committed in r134059, but removed again in r134074. The fix should be re-committed and kept for a minimum of one year.


> I also hacked (someone else's) Portfile once to get rid of the
> leftovers on the buildbot (after the admins didn't reply for more than
> 24 hours) and it worked. But it left weird history in SVN of that
> Portfile which was undesirable side effect.
> 
> I suggested that we should introduce a dummy port for these kind of hacks.
> 
> Otherwise someone could write a script and introduce a special button
> on the buildbot to remove any leftovers between the builds (similar to
> force build, there could be a force clean button; or force build a
> "clean-the-buildbot" port). Removing the leftovers could also be part
> of the standard cleaning step. After all the ports are deactivated, a
> script could check whether there are any files in $prefix that weren't
> supposed to be there and remove them.

I don't think we need any of that. Ports should not write outside the destroot, except in very unusual circumstances, or in the more common circumstance of a port that wants to copy a sample configuration file to its final location in a pre-activate block. Ports that have inadvertently violated that should be fixed, and a workaround for error-free upgrades (i.e. a pre-activate block to remove the offending file) added to that port.