[ANNOUNCEMENT] Updated: rebase-4.1.0-1

[Ryan Johnson]

On 27/03/2012 4:36 AM, Corinna Vinschen wrote:
> On Mar 26 22:59, Ryan Johnson wrote:
>> On 26/03/2012 9:40 PM, Jason Tishler wrote:
>>> New News:
>>> === ====
>>> I have updated the version of rebase to 4.1.0-1.  The tarballs should be
>>> available on a Cygwin mirror near you shortly.
>>>
>>> The following are the changes since the previous release:
>>>
>>>      * Add rebase/rebaseall touch file (i.e., -t option) support.
>>>
>>>      * Add rebaseall setup (i.e., -p option) support.
>>>
>>>      * Add .oct to the default rebaseall suffix list.
>> I've been meaning to ask... but maybe the above-mentioned -p flag
>> obsoletes it now: What's the most efficient way to rebase after
>> running setup? We've had the rebase db for a while now, so running
>> rebaseall seems like overkill. Only the newly downloaded dlls need
> Now that the new rebase is out, I'm going to create an _autorebase
> package which will automatically call rebaseall at the end of a
> successful run of setup, if that run also updated existing DLLs or
> came with new DLLs.
>
> In some cases this might take two minutes or so at the end of a setup
> run, but at least we should see less rebase problems in future.
That will be awesome.

> The most efficient way would be to change rebaseall so that only
> DLLs are given to rebase which are updated or new.  But rebaseall
> would still have to search the files in /etc/setup.  And rebase
> still opens every DLL in the DB and from the command line to see
> if the DB and reality are still in sync, and to decide which DLLs
> have to be rebased and which are not.  So I'm not sure you can
> make it much faster, unless you make the algorithm in rebase itself
> faster.
Honestly, I don't care if it's slow, just so it works. The problem right 
now -- at least in my naive invocations -- is that rebaseall attempts to 
rebase things which are in-use. Perhaps the initial in-sync-ness check 
opens the file in exclusive mode and fails? I know the in-use files were 
still in sync because they were when setup started. Setup didn't 
complain about anything and I didn't start any new processes after it 
completed.

Another idea: right now rebase[all] seems to give up if it encounters an 
in-use file. Can it just skip the file and keep going?

> Needless to say that the ultimately most efficient way would be
> to find a method to avoid rebase problems after fork at all.  The
> last attempt at it looked promising at first, but then again...
> http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/afdf1b68-1f3e-47f5-94cf-51e397afe073
That did look promising... I only run in a console under duress, but 
losing LoadLibrary is a deal-breaker.

Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple