A beginner's Cygwin question here - I'd like to install a newer version of Cygwin (the latest, which is 1.7.9) on a few Windows 2008 Server boxes which currently have rather an old version (1.5.25). I need to do an offline, silent install, and I'm currently deciding whether to do some sort of manually produced list of changed/added/removed files, or just replace the old install with the new. The install is quite big (80 odd megs), so just doing the differences might make sense here. It looks like there is nothing in the way of registry servering or so on required to install Cygwin -you just copy the files somewhere, add it the the path and you're good to go.
One problem, though, is that looking at what's changed between old and new reveals that some of the files the most recent install has used are actually older versions that what we've already got. Ie cygintl-8.dll, envsubst.exe, gettext.exe. Surely you can't mix and match versions?
I'd appreciate it if a more experienced Cygwin user could reply with a few hints as to the best approach here.
There's always an official config.ini file that lists a recommended version of each package, plus often both newer and older versions than the recommended one. When you do an installation with setup.exe, you can elect to use the bleeding edge versions for some or all of the packages. Perhaps your 1.5.25 version was installed with all the bleeding-edge packages, and the 1.7.9 just accepted the defaults. It's not unlikely that some sets of old/current/new packages hadn't changed between those two cygwin versions.
In general, you can mix and match a lot of things, just as you can on Linux. You can't take an old version of the core cygwin1.dll library and expect new packages to run against it; but not all the packages have to be in lockstep.
Related
I've been using NVM for Windows to run two versions of Node on my system, the latest version and the LTS version. However, I haven't updated Node since installing NVM. I would like to update both versions to their current iterations (11.5.0 and 10.14.2 at the time of writing), ideally without having to reinstall all of my global packages for each. I know the original NVM has this capability with the --reinstall-packages-from flag, but it doesn't look like there's anything similar in NVM for Windows.
You're right, there's nothing similar in NVM for Windows. If it would be useful for you, you could always request it by opening an issue on the github page.
It sounds like you already know how to install 11.5.0 and 10.14.2, and that once you do, running nvm use 11 or nvm use 10 will automatically select the latest appropriate version (but you'll still have to manually reinstall any global packages).
This might be an opportunity to take stock of global packages, they often cause more trouble than they are worth. (In general, the fewer global packages installed the better.)
It's unsupported by design
https://github.com/coreybutler/nvm-windows/issues/236
NVM4W provides a more minimalistic approach, focusing on node version
management, not npm management. NVM4W leaves workflow customization to
the end user... because a) it's not hard, and b) it's very
opinionated.
The statement "switching node version needs reinstallation of all
packages in most cases" is unsubstantiated. This doesn't mean it's not
true, but there aren't any stats to back this claim. There are plenty
of use cases where this is not the case, such as developing original
modules with forward/backwards compatibility.
Third, automating this process, either forcibly or by default, has a
number of unintended consequences in a Windows environment. See the
Roaming Profiles use case for an example.
Even if this were a non-default optional command, it still strays from
node version management into npm management. This is an entirely
different problem (and a much bigger problem).
I am using debian and the haskell-platform on the system gets really old. So I download the newest haskel-platform binary version and place it under /usr/local/haskell and activate it. Now there're 2 versions of ghc. If I type ghc then the old ghc-7.4 will be used and ghc-7.8.3 will certainly call the new one. But I have trouble with cabal. The new cabal cannot be used because of glibc version. Can I make the old cabal work with the new haskell platform ? If so how can I make it work just like there're two cabals. In the other word, I want the default directory of the cabal working with the old platform to still remain $HOME/.cabal and the cabal working with new platform to become the new directory (actually I don't know where). Can anyone help me to configure it so that I can have two versions of haskell-platform working separately on my Linux.
You can use lots of GHC installations at the same time without problems, but I don't think that's true for multiple Cabal installations. All you need is to use up-to-date Cabal, no need to keep any other versions. See this blog post for how to use multiple GHC's: http://osa1.net/posts/2014-12-09-ghc-cabal-installation-guide.html
I have a machine running FreeBSD and the ports tree is accidentaly updated to one of FreeBSD 8 stable. The problem is that my FreeBSD 8.1 is not configured to use PKG for packages so I cannot update or install packages.
I want to upgrade the machines FreeBSD but get the ports tree in working order before I do that.
It seems the only solution is installing an old 8.1 version of the ports tree, but I cannot find any.
Can someone tell me where to find this?
Would upgrading to the lastest stable version 8 also solve my problem?
As far as the "8.1" tree, you can find that by using svn to checkout ports/tags/RELEASE_8_1_0 instead of ports/head but keep in mind this tree is going to be terribly out dated and have lots of insecure software and many things are not even going to fetch properly any more. This is probably not the way to go.
Instead, you are better off upgrading to 8.1, but that is one of two steps needed to fix your situation. The other step is to switch to pkg(ng). The way to do that is to run pkg2ng. See the handbook section on pkgng for more details. Running pkg2ng is a one time operation and doesn't require rebuilding or re-installing all your ports. Instead this just tells pkg about the existing software so it can manage it.
Is there any way I can go back and install a older version of Cygwin?
Say I want the 1.7.9 version, but the setup.exe in the Cygwin website always point to the latest release?
http://www.cygwin.com/setup.exe will always point to the latest release. The only previous release available at cygwin.com is the 'setup-legacy' file, which is version 1.5.25 and is compatible with older versions of Windows. Downloading older versions of Cygwin is discouraged because of incompatibility with the latest available packages.
That said, if you are certain you want an older version of setup.exe, the only way to get it would be to find the file mirrored elsewhere. Simply google the specific version you want, and you should be able to easily find what you are looking for. download.cnet.com, for example, has many previous releases: see for yourself.
In summary, there is no 'official' way to get previous Cygwin releases, so you will have to find a mirror of that specific release.
Yes, see this answer but ignore the parts about Postgres
https://serverfault.com/a/532412/123651
Install an old version if you have to. Someone maintains a historical archive of Cygwin versions.
Browse the time stamp of the setup.ini file you need: http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html
Copy the address of the folder (not index.html)
Run /setup-x86.exe -X with the -X option to ignore setup signatures (they aren't archived).
Paste the address into the dialog to choose your download site. You will then see a snapshot of packages available during that time.
Then pick the Cygwin base package to get an older version.
Download any setup version from https://cygwin.com/setup/
I have about a few problems with a new install of the Qt SDK. I probably only need advice, but specific answers are also welcome. Before I begin a mini-story, I am running RHEL5 on academic license under VirtualBox on OSX 10.6. Using Qt version 4.5.3. This is my situation...
1.) I couldn't compile because g++ wasn't found. I fixed this by creating a link: g++ -> g++34. This allowed me to compile but it generated more errors at link-time. I had installed the framework in my home directory unintentionally so I uninstalled/reinstalled the entire SDK to /usr/local/qt.
2.) At this point I could compile but the linker complained about a missing freetype package. I had that already installed but wasn't sure why it couldn't be found. So I installed a few packages that I thought might be missing like libqt4-devel and libqt4-devel-debug. I also installed a few other general programming packages for later use.
3.) Somehwere in this process I can no longer run qmake. I ran it before and I have it installed at /usr/local/qt/qt/bin/qmake. I could create a link to it (though I shouldn't have to OR I could ensure that the location was in the PATH var). However, at this point Qt Creator says there's no Qt installation found. I re-pointed it to the installation location (using Tools/Options) but it still won't run qmake or anything else for that matter...
I only need this linux install to compile and test my Qt projects which I am developing in OSX. So my question is, should I just wipe this RHEL install and start over? And if so, should I use something else like Ubuntu? I am having plenty of hassles that I don't want to deal with as is. Note, this project will require good OpenGL support.
Is there a particular reason that you don't simply use the Qt package that's part of RHEL?
If for some reason you need to build your own, you can get all of the build dependancies with:
$ yum install yum-utils
$ yum-builddep <whatever the qt package's name is>
#scotchi is right, and you should try to use the Qt package that comes with your system unless you need a very different version. I don't know what version of Qt comes with RHEL but if its not up-to-date enough for you (and it might not be, see below) then you could consider changing OS versions. I would only do this after trying his suggestion though, because you may be able to get things working without the hassle of a full OS install.
Now, as to why you might want to switch: RHEL is, as its name ("Enterprise Linux") indicates aimed at companies who want to run servers, or large deployments of desktops. It emphasizes stability and reliability over being cutting edge. Fairly often the version of the compiler and development libraries lag a little behind the curve. This is what their clients want: a stable platform they can develop against and run programs on for a period of time, not constantly needing to keep up with the latest changes, and thoroughly tested. But for people doing development at home it may not be necessary to stay that conservative. I don't know if this is for work, school or personal programming, but it sounds to me like you should move to one of the more desktop-oriented distros. Ubuntu is great, as is Fedora. If you prefer a RHEL-like environment, then choose Fedora.