This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: setup
- From: Warren Young <wyml at etr-usa dot com>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 10 Aug 2015 09:02:17 -0600
- Subject: Re: setup
- Authentication-results: sourceware.org; auth=none
- References: <87mvy8f8dz dot fsf at Rainer dot invalid> <20150803202908 dot GI17917 at calimero dot vinschen dot de> <87a8u8f4s5 dot fsf at Rainer dot invalid> <871tfidhrm dot fsf at Rainer dot invalid> <20150805080833 dot GT17917 at calimero dot vinschen dot de> <87614tn3nm dot fsf at Rainer dot invalid> <20150806100338 dot GY17917 at calimero dot vinschen dot de> <87d1z0if40 dot fsf at Rainer dot invalid> <20150807194737 dot GO12475 at calimero dot vinschen dot de> <FDE4E5FD-6406-41CE-BCAE-9CD9EA817B68 at etr-usa dot com> <20150810084356 dot GA13029 at calimero dot vinschen dot de>
> On Aug 7 15:05, Warren Young wrote:
>>
>> Youâd have to couple this either with a MoveFileEx(â,
>> MOVEFILE_DELAY_UNTIL_REBOOT) call or a background task that replaces
>> /bin/setup.exe with %LOCALAPPDATA%/Temp/setup-v$next.exe.
>
> Why?
I was assuming a world where setup.exe lives in /bin and you can call it from Bash. (In such a world, I hope it gets renamed to something less generic, like cygpkg.) I was further assuming that setup-*.tar.xz would be packaged the same as any other Cygwin package, unpacking directly into /bin.
Thus, the MoveFileEx() call would be the one setup.exe normally offers, where it sees youâre trying to replace an in-use executable.
I was offering the background task alternative as a way around that. However, the rest of your reply gives me a different idea.
> The idea is that setup is called, performs a CopyFile of itself
> and then exec's its copy.
If you mean that it always copies itself to some kind of temp space and execs it from there, that feels kind of wasteful, since youâre trading my design that copies only when required for one that copies every time.
But what if we invert it? Why couldn't setup-*.tar.xz package unpack into /tmp? The running setup.exe would exec it there with a flag that causes the second setup.exe instance to copy itself back into /bin. Then there is only a copy made when setup.exe is actually being replaced, and /bin/setup.exe is kept up-to-date.