On 7/7/2018 8:40 AM, Jon Turney wrote:
On 06/07/2018 15:05, Jon Turney wrote:
On 06/07/2018 14:51, Jon Turney wrote:
Thanks for the patch.
The version is checked (again), at ini.cc:404
I've never understood why we have this twice.
(I think the idea might be that first we are checking the
On 06/07/2018 15:05, Jon Turney wrote:
On 06/07/2018 14:51, Jon Turney wrote:
Thanks for the patch.
The version is checked (again), at ini.cc:404
I've never understood why we have this twice.
(I think the idea might be that first we are checking the setup
version as a proxy for the
On 06/07/2018 14:51, Jon Turney wrote:
Thanks for the patch.
The version is checked (again), at ini.cc:404
I've never understood why we have this twice.
(I think the idea might be that first we are checking the setup version
as a proxy for the setup.ini format version, to warn if there might
On 05/07/2018 19:34, Ken Brown wrote:
The instruction that setup currently emits telling you to update setup
won't make a lot of sense if setup is then going to update itself
I'm attaching a patch to setup that adds a new option,
--no-version-warning, to suppress that warning. (The patch
On 7/5/2018 3:26 PM, Achim Gratz wrote:
> Ken Brown writes:
>>> Not sure that when the setup package is upgraded, setup will be able
>>> to remove itself, though.
>>
>> I've just tested this, and in fact the running setup doesn't remove itself.
>
> It would have scared me if it did.
>
A scheme
Ken Brown writes:
>> Not sure that when the setup package is upgraded, setup will be able
>> to remove itself, though.
>
> I've just tested this, and in fact the running setup doesn't remove itself.
It would have scared me if it did.
>> (Old setup-${VERSION}-${RELEASE}.exe lingering may be a
On 4/11/2018 12:56 PM, Jon Turney wrote:
On 11/04/2018 00:14, Ken Brown wrote:
On 4/10/2018 2:12 PM, Yaakov Selkowitz wrote:
In order to speed up the adoption of the latest setup.exe, would it make
sense to ship it as a package? Here is an initial draft of what this
might look like:
Jon Turney writes:
> Also, I guess ideally setup should update itself first, rather than at
> the same time as all other packages...
Please keep an option to not do this and especially not try to access
anything over the network. Setup still needs to be able to work from a
local archive only.
On 2018-04-11 10:56, Jon Turney wrote:
> On 11/04/2018 00:14, Ken Brown wrote:
>> On 4/10/2018 2:12 PM, Yaakov Selkowitz wrote:
>>> In order to speed up the adoption of the latest setup.exe, would it make
>>> sense to ship it as a package? Here is an initial draft of what this
>>> might look
On 11/04/2018 00:14, Ken Brown wrote:
On 4/10/2018 2:12 PM, Yaakov Selkowitz wrote:
In order to speed up the adoption of the latest setup.exe, would it make
sense to ship it as a package? Here is an initial draft of what this
might look like:
On 4/10/2018 2:12 PM, Yaakov Selkowitz wrote:
In order to speed up the adoption of the latest setup.exe, would it make
sense to ship it as a package? Here is an initial draft of what this
might look like:
https://github.com/cygwinports/setup/blob/master/setup.cygport
Note that the executable
In order to speed up the adoption of the latest setup.exe, would it make
sense to ship it as a package? Here is an initial draft of what this
might look like:
https://github.com/cygwinports/setup/blob/master/setup.cygport
Note that the executable itself is version/release-numbered so that we
12 matches
Mail list logo
