This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] Updated: rebase-4.1.0-1

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
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...
That did look promising... I only run in a console under duress, but losing LoadLibrary is a deal-breaker.


-- Problem reports: FAQ: Documentation: Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]