Buildbot cruft: /opt/local/bin/mvn31

[Mojca Miklavec]

On Wed, Mar 18, 2015 at 7:40 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> 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.

I noticed and corrected myself in the next email. I'm sorry, I didn't
read the thread carefully enough earlier.

>> 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.

This is an example of a port that clearly violated the rules, in a
reproducible way.

But there are times when an error occurs on the buildbot and those
cases might result in leftovers on the buildbot even if the Portfile
and the software are properly written. Usually only a single buildbot
is affected.

Mojca