This is the mail archive of the cygwin-apps 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: [PATCH] setup: implement "perpetual" postinstall scripts


On Wed, Feb 06, 2013 at 11:16:17PM +0100, Achim Gratz wrote:
>Christopher Faylor writes:
>> You should make it clear why the current mechanism is unsatisfactory.
>
>I thought I already had, apologies if I haven't been clear enough.  In
>general the changes that I've posted for review aim to enable either an
>unattended or a guided install (choser mode) that does the initial
>install or combinations of installing/removing packages and updating
>Cygwin with just a single start of setup.exe and no or (in guided mode)
>minimal user interaction.

I don't really see how making setup.exe always run rebaseall makes
unattended installs work better.

>I originally did the rebasing from the install script that also calls
>setup.exe, but I've had several cases where the postinstall scripts
>would not run correctly without the rebasing done first and that meant I
>would have to check if Cygwin was already installed and then run rebase
>twice (aside from running setup.exe twice, one time for installation and
>the other for updating already installed packages).  With all my changes
>integrated I can now do all of this in a single invocation of setup.exe
>and that is a real improvement since each invocation of setup.exe scans
>the release directory before it does anything and that is very slow when
>accessing the distribution server (typically about three minutes).
>
>> _autorebase is already designed to be run whenever a dll is updated.
>
>To the best of my knowledge that works by auto-incrementing the package
>version, so it is only ever effective when another Cygwin package that
>needs rebasing updates, but doesn't really do anything if the user adds
>libraries through other venues (CPAN, gems and the like).  The solution
>that I've implemented doesn't rely on the package version to decide on
>when to run, it is instead _always_ run (it first checks if there's
>anything to do so the cost of doing that is low).  This enables setup to
>be run for the sole purpose of doing either an incremental or a full
>rebase, something that either won't work or is much more difficult to do
>with the current solution.

???  If we need to rebase dlls then we should just run rebaseall.  There
isn't any reason to tell people to run setup.exe to do that.  If the
problem is that people are installing third-party dlls then they should
get in the habit of running rebaseall.  We don't want people superstitiously
running setup.exe expecting it to solve their problems even when there
are no new packages to install.

If we can't expect the unwashed to run autorebase then we could have
an autorebase daemon running which just attempts to rebase dlls that
it hasn't seen before every N minutes.

Sorry but I don't think this is a good idea.

cgf


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