I am running Mac OS 10.7.5, and I was wondering how I can install an older version of git. Also, which version do people recommend? Since I get C files if I download an older version, do I run them with my bash profile?
Related
I've got a machine running an unsupported OS (rhel6.3). It no longer has access to current repos, and cannot be updated for budget reasons.
It needs to have tzdata updated, but the only version it has access to is from 2014.
tzdata is a noarch package - it's just a bunch of binary files - so it doesn't matter if I grab it from another repo, say, our local yum repo which has the latest tzdata packages for other OSs, like centos7.
I know I can simply download and put the latest tzdata rpm locally on the rhel machine, but I'd like this process to be automated - as in, Puppet checks that tzdata is the latest version - and not have to manually go put it in place whenever the tzdata is updated.
Is it possible for Puppet to specify, use this repo, but use the rpm specified for another OS?
tzdata is a noarch package - it's just a bunch of binary files - so it doesn't matter if I grab it from another repo, say, our local yum repo which has the latest tzdata packages for other OSs, like centos7.
Being a noarch package has no such implication. "Noarch" packages are independent of machine architecture, but not necessarily of OS version. For example, many Python packages are noarch, but the Python2 in EL6 is version 2.6, whereas the Python2 in EL7 is version 2.7. Noarch Python packages for EL7 do not work properly on EL6 if they rely on any of the features introduced in Python 2.7. If they are well packaged then such packages won't even install on EL6.
I suspect you're ok with tzdata in particular, but there is always a possibility that there has been a change or addition to the format of the packaged files that renders them unusable on older OS versions. You should be pretty safe, however, if you go with the CentOS 6.7 package for your EL6.3 system, rather than any EL7 package.
Is it possible for Puppet to specify, use this repo, but use the rpm specified for another OS?
Packages in the same Yum repo are not distinguished by OS or OS version. Where and to the extent that different OS flavors or versions must be served different package collections, it is done by giving them altogether different repos. So no, there is no way to instruct Puppet specifically as you describe, because there is no way to instruct yum that way.
On the other hand, if you have a local repo that is enabled on the target machine, then you can indeed drop a package built for some other RPM-based distro [version] into that repo. Clients will see it, and will (attempt to) use it where appropriate based on its name and epoch-version-release codes. You don't need to do anything special to make that happen.
On the third hand, you could also consider getting the source RPM for the version of tzdata you want, building the binary RPM from it on your EL6.3 machine, and dropping that in your local repo. You can get all manner of source (and binary) RPMs for Fedora and RHEL from Koji.
I've compiled a C program under Ubuntu 12.04, built a Debian package out of it, and want to install it on a server running Debian Lenny.
Last time I did that (about two months ago) it worked: I could install the package and run the binary. But now I get the following error message:
(binary's name): /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by (binary's name))
Other than upgrading my machine to Ubuntu 12.4, the only significant change we've brought to the code is a call to strdup(), for which I had to enable the _POSIX_C_SOURCE=200809L feature test macro.
Upgrading the server to the latest Debian version is not my preferred option as it is not under my direct control.
How do I fix this problem?
I think the critical bit of info here is 'upgrading my machine'. So when this worked before, you were building and packaging on something earlier than 12.04? If so, then the issue is that 12.04 now ships with a newer version of libc (apparently 2.14), and your binary now records a dependency on that version of libc. When you try to run on Lenny, which likely uses an older version of libc, the linker detects that the Lenny version does not support the 2.14 API, and fails.
I think the best way forward is probably to do your development and testing on 12.04, and then when you want to create packages for a specific Debian release, use pbuilder or similar to create debs. This will ensure that the libraries used for the packaging build match the target platform.
I would like to install the php-intl extension for PHP on my Mac. I know the current PHP installation was installed with the OS (Mac OS X 10.6).
So I am wondering if I install the php5-intl package using Macports, will it install a second version of PHP (which I don't want), or will it upgrade my existing installation?
If I can't upgrade my current PHP installation that way, how can I proceed?
Installing the MacPorts php5-intl port will install PHP's intl extension for use with MacPorts php5, which it will also install; you'll also get MacPorts' copy of the apache2 server. MacPorts is designed to be self-contained; it's not designed to modify or integrate with any software components Apple provided with your OS. This is a good thing; Apple occasionally makes unexpectedly changes to their OS components which could break things installed by MacPorts.
If you want to give MacPorts apache2 and php5 a try, check out the MacPorts MAMP guide in the wiki.
I see there are many version of autoconf and automake available in my ubuntu linux.
If I want create a new project from scratch, what's best choice, latest versions or older versions?
Go with the latest version. It's only developers who are rebuilding the configure system that need to use autoconf and automake (and thus need to have the newer version installed), which likely just means "you"; it won't affect users who are just building your project using your distributed configure files.
I just got Macports installed on my mac, of which os version is Snow Leopard (10.6). I used Macports to install several packages through 'sudo port install' command, and all these packages are reported active after the installation. I just wonder that whether these packages are really working? For example, macports tells me that 'gcc44 #4.4.2_0 (active)', however in python it says '[GCC 4.0.1 (Apple Inc. build 5493)] on darwin'.
So I just want to know that if there is some problem with my method of installing or my macports needs some configuration after installation?
Any help is appreciated! I am really new in Mac OS.
I believe Python is declaring the version of gcc used to build it which should be the gcc installed on your Mac i.e. the version that came with the Mac OS Development tools. This should be located in /usr/bin/gcc.
You should find the gcc version matches when you execute
/usr/bin/gcc -v
I do not think anything is wrong with your setup or configuration. It just shows Python was compiled using the gcc provided by Apple
Macports installs software not to conflict with the versions provided by Apple. If they replaced the C compiler and libraries, really bad things might happen when Apple provided operating system updates.
gcc is the command for Apple's version of gcc, at /usr/bin and version 4.0.1 for Leopard.
gcc-mp-4.4 is the command for gcc version 4.4 as provided by MacPorts, located at /opt/local/bin.
Similarly there will be versions of python in /opt/local/bin.
Like houmam, I prefer to explicitly invoke versions by name. If you want to connect particular versions to python, I think that the MacPorts package python_select (this has now been replace by port select python) implements this by using symbolic links. I've never used it.
It probably is just that compiler that was picked by the build was that installed by XCode. You can try typing which gcc to see which one is in your path. The macports one would by default be in /opt/local somewhere.