This is the mail archive of the
mailing list for the Cygwin project.
- From: Warren Young <wyml at etr-usa dot com>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 10 Aug 2015 11:09:34 -0600
- Subject: Re: setup
- Authentication-results: sourceware.org; auth=none
- References: <87vbcwfdvw dot fsf at Rainer dot invalid> <87r3nkfaxn dot fsf at Rainer dot invalid> <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> <874mkawe0c dot fsf at Rainer dot invalid> <FA0668B5-C99E-49AD-9947-28DBD595A06B at etr-usa dot com> <87tws7rtb2 dot fsf at Rainer dot invalid> <950B17ED-5523-40A7-9CF5-CB21434591B9 at etr-usa dot com> <87pp2vrsd0 dot fsf at Rainer dot invalid>
On Aug 10, 2015, at 11:00 AM, Achim Gratz wrote:
> Warren Young writes:
>> Isnât the whole point of this discussion that setup.exe already knows
>> all the tricks it needs to in order to do what we want here, except
>> for the âreplace setup.exe in placeâ issue Iâve brought up separately?
> Well, setup.exe today has a lot of probably bitrotted features that
> Cygwin never used (even if some of it looks quite interesting and
I donât think there is any call for setup.exe to be highly backwards-compatible. It isnât asked to deal with old package repos, very old versions of setup.ini, etc. Therefore, I would say that whoever is in charge of this code base should simply get rid of the bitrotted features.
If any of these obsolete features are needed again in the future, they can be pulled out of the SCM history.
> there are other things it doesn't do even though it should
> probably be doing it.
>> Why do you need a self-contained POSIX environment to replace
> At the moment I'm just thinking whether that might be a more sustainable
> way forward.
Replacing core infrastructure like this almost never works out smoothly, and usually fails outright. Itâs far better to remediate the code base in-place, if at all possible.
There have been a bunch of attempts in the past at replacing setup.exe. At least 3, that I can think of. All have fizzled.