Re: setup
Warren Young writes: But that’s a side issue, because I don’t see why you think you need Busybox in the first place, unless it is to be able to run postinst scripts. Can’t you just say that that setup-*.tar.xz package never has a postinst script, so that all you need to do is un-tar it? The idea was that you have a fairly complete POSIX environment with as small a footprint as possible, then use that to bootstrap a more conventionally styled Cygwin install. In that sense, setup.exe is already bootstrapped: it has everything within itself to be able to replace itself. I do like the concept of a self-contained executable, but teaching setup.exe new tricks is likely a larger effort than adding a script here and there to an install system. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: setup
On Aug 10, 2015, at 10:40 AM, Achim Gratz wrote: Warren Young writes: In that sense, setup.exe is already bootstrapped: it has everything within itself to be able to replace itself. I do like the concept of a self-contained executable, but teaching setup.exe new tricks is likely a larger effort than adding a script here and there to an install system. 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? Why do you need a self-contained POSIX environment to replace setup.exe?
Re: setup
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.
Re: setup
Corinna Vinschen writes: Link? I'd think Jon needs to give his OK for me to post it or he should post it himself. I'm using setup with the -m option exclusively so I'm mostly interested that this still works. That's pretty extensively tested by now since that is what I use for the installations at work. However, you might want to make a quick list what scenarios you want to have tested as well. I try to do that over the next couple of days and hopfully other maintainers try, too. Installs from the internet (with and without proxy) and ad-hoc installs of single packages and package groups from a local directory that doesn't have a setup.ini. IIUC, you mean that the current method of downloading setup only from sware should be maintained? What kind of key are you talking about? Currently the integrity of setup.exe and therefore the whole installation hinges on it being downloaded from sware via https, so that's a strong reason to keep it that way. The key I'm talking about was that in addition to setup-version: we could have an additional setup-trial-version or something like that would inform setup that a successor is waiting in the wings. That's a general problem. I'm not sure how much exposure the Cygwin test DLLs really have, either. I'm reasonable sure that some of you maintainers are using them, but otherwise it's a bit of a black hole. You should at least be able to find out how often they were downloaded. For setup trial versions this isn't enough, so they'd have to contact sourceware and HEAD/GET something that indicated success or failure (and some script to extract that out of the logs on sourceware). It also must not be sneaky about this, ideally the user consents before the trial version gets downloaded at all. Not sure I follow. How would such an install system look like? I have a vague notion that busybox could run the scripts, but there are installation path issues and requirements of some postinstall scripts which might not be suffiecently handled by busybox. I have done a few manual installations from a running Cygwin onto a cold installation on the same machine, mainly to switch out the Cygwin DLL. You need to mount the other Cygwin somewhere (I use /mnt/cygwin or something like that) and then redirect the install root there (tar -C /mnt/cygwin). The postinstall scripts on the other hand must be started from within the new Cygwin installation anyway. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: setup
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 useful) and 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 setup.exe? At the moment I'm just thinking whether that might be a more sustainable way forward. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: setup
On Aug 10, 2015, at 12:03 PM, Achim Gratz wrote: 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. These were? The Debian and Red Hat packaging systems have both been ported to Cygwin. Those could be used along with a bare-bones setup.exe to bootstrap Cygwin, after which setup.exe would no longer be needed. https://github.com/transcode-open/apt-cyg https://cygwin.com/ml/cygwin-announce/2003-05/msg1.html Then there was a pretty GUI installer someone made many years ago; I believe we were still in the 1.5.x line at the time. I don’t remember enough about it to find it via Google again, but I do remember a few posts to the mailing list with positive responses. Then the developer disappeared and no one took up the code base. That’s part of what I mean about the difficulty of replacing key infrastructure. Without either a change at the core or an overwhelming attack from outside, there just isn’t enough reason for someone to try to adopt something nonstandard. Without that user base, there isn’t enough drive to continue development, so the project fizzles. Consider the rise of Ubuntu-based Linuxes, replacing the various the RPM-based ones. That didn’t happen purely because Ubuntu was “better.” A necessary part of this was Shuttleworth pouring millions of dollars from a really lucky IPO into the project. As proof, consider all of the Ubuntu clones that have gone nowhere, despite being “better” in some way. The closest thing I can think of to success in the area you propose to tackle is mintty, which stepped into a gap between Windows Console and Cygwin/X + rxvt. It didn’t try to replace either one, exactly, so it didn’t have to succeed by first making the other disappear. “Better and separate” beats “better.”
Re: setup
Warren Young writes: 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. That's my sentiment as well, but that doesn't preclude the exploration of alternatives. 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. These were? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: setup
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 useful) 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. Okay, but... Why do you need a self-contained POSIX environment to replace setup.exe? 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.
Re: setup
On Aug 7, 2015, at 11:22 PM, Achim Gratz strom...@nexgo.de wrote: a minimal Cygwin install system w/ busybox Busybox isn’t going to be usable in its normal sense without cygwin1.dll to map symlinks to argv[0] so that Busybox can tell how it was called, and thus which function to provide. But that’s a side issue, because I don’t see why you think you need Busybox in the first place, unless it is to be able to run postinst scripts. Can’t you just say that that setup-*.tar.xz package never has a postinst script, so that all you need to do is un-tar it? In that sense, setup.exe is already bootstrapped: it has everything within itself to be able to replace itself.
Poco: Please remove empty directories
With the release of poco-1.6.1, I've decided to do some housekeeping and remove some of the earlier versions. I've managed to do this, but it has left some empty directories lying around. Please could some kind soul remove the following: x86_64/release/poco/libpoco16/ x86_64/release/poco/libpoco17/ x86/release/poco/libpoco17/ Is there a way I can remove directories myself, or should I continue to ask here in future? Many thanks in advance, Dave.
Re: Poco: Please remove empty directories
On 10/08/15 22:49, Yaakov Selkowitz wrote: On Mon, 2015-08-10 at 22:29 +0100, David Stacey wrote: With the release of poco-1.6.1, I've decided to do some housekeeping and remove some of the earlier versions. I've managed to do this, but it has left some empty directories lying around. Please could some kind soul remove the following: x86_64/release/poco/libpoco16/ x86_64/release/poco/libpoco17/ x86/release/poco/libpoco17/ Done. Thanks, Dave.
Re: setup
On Aug 7 15:05, Warren Young wrote: On Aug 7, 2015, at 1:47 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Aug 6 17:57, Achim Gratz wrote: I would consider this a release candidate. Some more testing with interactive and ad-hoc installs would be useful, though. I have a vague idea that setup should ideally be part of the Cygwin distro package set. So setup updates itself, and it would be possible to handle public test releases. The issue of overwriting setup while setup is running could be worked around by setup first copying itself to a intermediate filename (e.g. .setup.exe) and then exce'ing that copy. 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? The idea is that setup is called, performs a CopyFile of itself and then exec's its copy. If the copyfile fails with a sharing violation or something like that, the copy is in use, which means, setup is already running. However, if the copy already exists and can be overwritten. it's just some older copy. I don't think there's a necessity to remove the copy at all. This would be a nice point to give setup.exe a CLI language for installing packages in yum/apt-get fashion, too. (Yes, yes, I know, SHTDI.) I like the idea in genral, but I'd also like to write SHTDI in all uppercase. Well, it already is, but you get my meaning... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpnX1OHe4uoa.pgp Description: PGP signature
Re: setup
On Aug 8 07:22, Achim Gratz wrote: Corinna Vinschen writes: I would consider this a release candidate. Some more testing with interactive and ad-hoc installs would be useful, though. How do you want to handle this? We don't have real provisions for setup.exe release candidates. True. At the moment it'd probably mean that some other folks on this list try it and give their GTG. They'd either have to build it themselves or maybe use the AppVeyor build from Jon Turney. Link? I'm using setup with the -m option exclusively so I'm mostly interested that this still works. However, you might want to make a quick list what scenarios you want to have tested as well. I try to do that over the next couple of days and hopfully other maintainers try, too. Maybe we should change how we provide setup updates in future? I have a vague idea that setup should ideally be part of the Cygwin distro package set. So setup updates itself, and it would be possible to handle public test releases. We could add a new key to setup.ini that indicates the existence of a test version and have setup ask if the user would maybe want to use that instead. Ideally setup would then download and exec it if the user choses to run it. IIUC, you mean that the current method of downloading setup only from sware should be maintained? What kind of key are you talking about? I don't have code ready to do that, though… Another problem that needs to be solved is to know how much exposure the new setup.exe really had to decide if it's good for release. That's a general problem. I'm not sure how much exposure the Cygwin test DLLs really have, either. I'm reasonable sure that some of you maintainers are using them, but otherwise it's a bit of a black hole. The issue of overwriting setup while setup is running could be worked around by setup first copying itself to a intermediate filename (e.g. .setup.exe) and then exce'ing that copy. Other ideas how we could handle this? As said before, the idea that setup.exe needs to be entirely self-contained is both an advantage and limiting what it can do. I haven't had time yet to check, but a minimal Cygwin install system w/ busybox might not be too large compared to the connectivity demands of todays' Windows itself. Here setup.exe would just need to unpack the current image of the install system and provide the GUI to pick the packages and control the actual installation. Not sure I follow. How would such an install system look like? I have a vague notion that busybox could run the scripts, but there are installation path issues and requirements of some postinstall scripts which might not be suffiecently handled by busybox. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpPv9oPV0Y8h.pgp Description: PGP signature
Re: Adding a subpackage
On Sat, 2015-08-08 at 19:39 +0100, Adam Dinwoodie wrote: On 08/08/2015 06:31, Achim Gratz wrote: Adam Dinwoodie writes: I've discovered a neat Git tool -- git subtree -- which is part of Git's contrib directory and isn't something we currently distribute as part of any of the existing Git-related packages. openSUSE ships this in git-core since some time. AFAIK the only reason it is still in contrib is the fact that it can't work on Windows. Yes, I discovered it at least in part via my Mac, where Homebrew installs it as part of the core Git installation too. I'd been planning on just adding it as a new package in Cygwin, without really thinking about whether that's actually the right thing to do; do you/anyone else think it'd be preferable to just roll this into the main Cygwin package instead of defining a new one? There seems to be a consensus among distros to include it as part of the main git package. I suggest we do the same. -- Yaakov
