[gobolinux-devel] [gobolinux-commits] tools/Scripts/bin SandboxInstall

[Jonas Karlsson]

On Fri, 20 Oct 2006 15:17:42 +0200, Hisham Muhammad <hisham.hm at gmail.com>  
wrote:

> On 10/20/06, Lucas C. Villa Real <lucasvr at gobolinux.org> wrote:
>> On 10/20/06, Jonas Karlsson <jonka750 at student.liu.se> wrote:
>> > CVSROOT:        /sources/goboscripts
>> > Module name:    tools
>> > Changes by:     Jonas Karlsson <mohjive>        06/10/20 12:34:40
>> >
>> > Modified files:
>> >         Scripts/bin    : SandboxInstall
>> >
>> > Log message:
>> >         Fix for bu #2, cleaning up target directory when fibo sandbox
>> fails
>>
>> I have been wondering about what to do with the program's contents in
>> this case. The trace file you've attached to the bug shows that there
>> was a binary file installed inside $target/bin.
>>
>> I think that we should take into account the user's choice on
>> "existing entry at /Programs, [r]emove, [k]eep, [w]hatever" when
>> cleaning up the broken installation: if the user has chosen to keep
>> it, just use the fix you've just commited; if the user has chosen to
>> remove it, the fix should also remove $target entirely.
>>
>> Does this look sane?
>
> In any case, that should not be implemented inside SandboxInstall.
> And *please*, let's keep the CVS tree frozen now that we're in release
> candidate status, and apply verified (as in, "patch discussed in the
> list") bugfixes only. As we could see yesterday, even "minor harmless
> commits" can introduce bugs.

Sorry, but this is my first RC. :)
I thought that for the final, we should use the same Scipts and Compile as  
on the RC unless a severe bug was found, to avoid such problems.
I also think that the tree should be branched so that those that don't  
work directly on the release can update the tools, without having to worry  
about breaking things for the RC.

Should all bugfixes go through the mailing list during rc status? What  
about this fix?

-- 
/Jonas

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/