12

I use Ubuntu Linux and I want to download an old version of an open source project to cut out and re-use some of its code that's not present in the current versions of this project. In order to do this I will need to be able to run the older version of this software.

However, it's important the current version continues to run without interference, and remains entirely unaffected by the old version's presence.

I don't want any mix ups or duplicates, and want to keep the two completely separated. Once I've taken the code I need, I plan to delete the old version.

Improve this question
1
  • 3
    This will likely depend on what the product is, how it installs, etc. I would recommend that you consider using a virtual machine and run the older software in the VM.
    – music2myear
    Commented Sep 3 at 23:47

4 Answers 4

Reset to default
19

I want to download an old version of an open source project to cut out and re use some of its code that's no longer supported.

If that's all you want to do, you don't even need to install or run the software. All you need to do is download the source code and browse it (in an IDE or just in a text editor) to find the code that you want to cut and paste.

The way to download the source code depends on how it's distributed. Nowadays a lot of open source projects have their code in a public distributed version control repository such as GitHub or GitLab. If that's the case, you can just install the appropriate version control software (e.g. git), clone the repository and then switch to the version you want (since the repository normally contains the entire development history of the software, including all versions ever released).

Note that cloning a git repository doesn't "install" anything to your computer. It just creates a directory with the source code for the software, plus a "hidden" subdirectory (named .git) that contains the version history in a compressed form, allowing you to switch between different versions of the source code. When you don't need the source code anymore, all you need to do to get rid of it is to delete the directory.

(In fact, you might not even need to download anything, since sites like GitHub and GitLab also let you browse the source code online and have the option to choose which "branch" or "tag" you want to view. This lets you view and copy the source code for older versions directly from the website. However, if you need to copy code from multiple files, cloning the repository may still be easier.)

If the source code is not available via git (or hg or other similar version control software), it may instead be distributed as a series of compressed archives (most commonly .tar.gz files, a.k.a. "tarballs", which you can decompress using tar -xz or most GUI file managers), typically one for each released version. This used to be more common in the past, but some older projects may still do it. In that case you need to download the source code archive for the version you want, decompress it into a directory and then browse that directory (just like you'd browse a cloned git repo) to find the code you want. Again, that doesn't require installing the software to your computer.

If you do want to also run the old version of the software, you can usually do that without permanently installing anything to your computer or interfering with other versions of the software you may already have installed. The precise details depend on the software in question, but there will almost always be a way to do this, simply because it's something that software developers need to do a lot.

Typically the source code repository (or tarball) will include instructions for building the software from the source code, often in a text file named BUILDING, INSTALL or README. This file (which might have a suffix like .txt or .md or just no suffix at all) will typically contain either plain text (readable in any text editor) or Markdown code (the same syntax that's used for writing questions and answers here on Stack Exchange, intended for rendering as "rich text" but also mostly readable in a plain text editor).

The specific instructions will vary depending on which build system the software uses, but it typically includes several phases:

  1. Pre-build configuration, which may involve either running an "auto-configure" script and/or manually editing a configuration file to e.g. specify which build tools you want to use, where to find any required libraries or other build dependencies, and which optional features you want to include in the built software.

  2. Building the software, which will compile the source code into an executable file (or several files) inside the directory that you've cloned the git repository (or unpacked the source code tarball) into.

  3. Testing, which will run some automated tests on the executable files built in the previous step to verify that they work as intended. (This is an optional step, but it can be very useful if you've made any changes to the code or if you're not 100% sure you've configured it correctly.)

  4. Either installation, which copies the executable files (and any additional data files they may need to run) from the building step into a shared directory (such as /usr/bin) from which any user on the system can run them, or packaging, which collects the executable files into an installation package (like an .rpm or .deb file) that can then be installed using a package manager (and possibly distributed to others to let them install it as well).

Again, the details may vary, but the important thing is that steps 1–3 should not require "root" or administrator access and should not modify anything outside the directory containing the source code repository. Thus, they will not interfere with any other software (including other versions of the same software) that you may have installed.

(The one exception is that you may need to install some libraries, compilers or other development tools to be able to build the software, and while it's usually possible to install those locally without admin access, it's often easiest to just install them globally using your system package manager.)

After step 2, you should be able to run the software from the directory you built it in. And to get rid of it afterwards, you still just need to delete the directory.

(Some software may require you to specify the path where it will be installed into and run from already in step 1. This can be awkward, but it may be required e.g. if the built executable files need to contain paths to data files. Often such software will include instructions for making a "test build", which can be run directly from the build directory without installing it anywhere else, or it will have some other way to allow testing the software without installing it. Because, again, software developers don't want to have to reinstall the software they're working on every time they need to test some change.)

Improve this answer
2
  • 2
    Some software may store its configuration in your home directory, meaning the old version might try to read (and fail) or write (and mess up) those files. Keep a backup.
    – Bergi
    Commented Sep 6 at 15:57
  • @Bergi: That's a good point. It's usually possible to change the location where the software looks for its configuration files (either with a compile-time setting or with a run-time command line option or environment variable), but if you don't do that, the default location might be the same as what your currently installed version of the software uses.
    – Ilmari Karonen
    Commented Sep 6 at 19:01
15

Given your requirements, a Virtual Machine is the correct solution to run the older version on. This will entirely prevent the different versions of the software interacting with each other at all.

Improve this answer
3
  • 1
    Nitpick: Not necessarily, as there are ways to break out of a virtual environment. This is considered a bug in the virtualization and not intended behaviour, and it's not really possible to do by accident, so unless the software they want to inspect is a specific sort of malware, this isn't relevant to the situation. But it's good to be aware that virtualization is not in general a completely isolated environment, and you still need to be careful with software you don't trust.
    – Hearth
    Commented Sep 4 at 14:21
  • 1
    A VM is an option, sure. Other options are a Docker container (see @James_pic's answer), or a chroot environment (see @wizzwizz4's comment), or build but don't install (see @Ilmari Karonen's answer), which I'd say is best for a simple "well-behaved" Open Source project. Another option would be build-and-install to a specific folder under /opt or $HOME, and use environment-variables to select which version of the software to use. On the other hand, if the software is malicious, a VM or Docker container with typical settings is still quite dangerous.
    – david
    Commented Sep 4 at 15:17
  • 1
    Given that we know this project and code have been around for a while and OP has used it for a while, we can assume it is highly unlikely the code will be malicious. As far as simple ways, using tools that are easy to use, to run code without impacting production, a VM is not the only method, but its a good method and has some advantages.
    – music2myear
    Commented Sep 4 at 15:40
3

If you only want to download the code (possibly to use elsewhere) and not run the application (the wording of the question is slightly ambiguous, but it seemed like this might be a possibility), you can download the source code for any package on Ubuntu with apt-get source. This will download the source code to a directory but will not attempt to build or run it.

If you want to run the application, then probably the easiest way to run it without interfering with the newer version of the application is to run it in a Docker container. Docker containers (and applications running in them) are isolated from the rest of your system, and have their own independent file system, so you could have a Docker container with the same version of Ubuntu, but with the older version of the package. Or with an older version of Ubuntu, or with a completely different Linux distro.

And of course it's possible to do both of these things - you can download the source, build a modified version of the package, and run the modified version of the package in a Docker container.

Improve this answer
2
  • I would recommend a chroot over a Docker container. Docker is non-trivial to set up, not that isolated, and is just a wrapper over chroot / unshare at the end of the day.
    – wizzwizz4
    Commented Sep 4 at 12:02
  • I considered also mentioning chroot, but my experience has been that getting a chroot correctly set up can also be non-trivlal, and of course it's even less isolated than Docker. In the end I didn't recommend chroot at least partly because I was less confident I could recommend how to do it correctly, but you're right that it's also a valid choice.
    – James_pic
    Commented Sep 5 at 8:43
0

If you want to run an older software, you can in most cases install it in a non-standard prefix like $HOME/old_software/softwarename or /opt/softwarename-0.1.2. These paths are normally not accessed by the system when running programname, so the software will not interfere with usual operation as long as you don't use the absolute path of the old version.

How to the installation prefix is configured depends on the build system, but in most cases it boils down to a simple command line option like

./configure --prefix=/opt/softwarename-0.1.2

or

cmake -DCMAKE_INSTALL_PREFIX=/opt/softwarename-0.1.2

To run the software you then later need to either set

PATH=/opt/softwarename-0.1.2/bin:$PATH

or run /opt/softwarename-0.1.2/bin/programname with the full path and possibly set

LD_LIBRARY_PATH=/opt/softwarename-0.1.2/lib

Doing so is not uncommon and for certain use-cases people even have a lot of old versions of the same software installed in non-standard prefixes without them interfering with each other.

For installing in /opt you will need to run the final install step (but not the compilation steps) as root or create the folder and give the current user write permissions.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .