Sorry if this has been asked before, can't find an answer.
Is there a way of installing two versions of Inkscape side by side (eg. stable and testing) on a Linux machine without compiling at least one of the two?

Well I've only ever used Windows, so I don't know about Linux. But for Windows, as long as you install them in different directories, you can install as many as you want, and without compiling. I think the same is true for all 3 operating systems. (I don't even know how to compile.)

I have 3 versions currently....at least. There might be another 1 or 2 floating around somewhere. (well no really "floating", but around somewhere)

With all the problems I'm aware of with 0.91, I'm finding it hard to settle on using either 32 bit or 64 bit Inkscape. Each one seems to have serious issues. Hopefully 0.92 will see some improvement.

Thanks for your reply, brynn. On Windows it's easy. On Linux however, by default the latest version replaces the older one.
So I'm still curious what a Linux user with experience in installing two Inkscape versions would have to say about this...

Interesting -- you mean when you install a new program on Linux, you aren't able to choose the location where it's installed? I've always had the impression Linux generally gives the user more control than the other os.

Afaiu, Inkscape works best on Linux, and....I'm not sure if this is the best way to say it, but it seems like I've read that Inkscape was orignally built for Linux. In any case, plenty of developers use Linux, and they must have several versions available for testing and programming.

But I'm sure someone will be able to answer this.

brynn wrote:Interesting -- you mean when you install a new program on Linux, you aren't able to choose the location where it's installed? I've always had the impression Linux generally gives the user more control than the other os.

Powerusers have total control, of course. Mere mortals just click a program (package) to install (heaven knows where), wait for the progression bar to finish and use. And then you have every user profile in between

But all that's between parenthesis. Back to the topic: how to install two Inkscape versions alongside each other in Linux (in mere mortal mode)?

Bartovan, I have been able to install two versions side-by-side (three actually - 0.48.5 from the repos, 0.91beta and 0.91release added manually) on my Linux Mint 17 box. It's not perfect (the 0.91 versions are missing some icons that are new with that version, because they're still trying to use the global icons file from 0.48) but it works well enough for me. Perhaps the first step would be to let us know what distro you're using, as I'm sure my instructions for Mint won't help you much if you're using Fedora!

Xav wrote:Perhaps the first step would be to let us know what distro you're using, as I'm sure my instructions for Mint won't help you much if you're using Fedora!

Oh yeah, sorry Ubuntu 15.04
What would interest me most is installing the current stable release, next to a beta or testing release.

Well I installed multiple versions by downloading the .deb file from the PPA site then extracting the contents (.deb files are xz archives - google for "extract deb" for details of how to do it). Then I was able to run the binary file in the extracted "bin" folder in my home directory.

As I noted, however, it still tries to use some system-wide files which could cause compatibility issues. Depending on how different the test versions are from your main installed version, this could cause significant problems.


Other alternatives would be to install in a chroot environment, a container, or a virtual machine with a minimal Linux installation on it.

I suppose a follow-up question would be: why not build it yourself? The instructions on the Inkscape website are pretty good and reasonably straightforward so long as you're not afraid of the command line. I've just given it a go myself and although it takes a little while to build (about 15 mins on my machine, using 4 cores) the process all went pretty smoothly.

Chroot and containers are definitely not something I want to, or am able to, venture into. That's over my head.

A virtual machine is a good and easy solution, although it seems rather "heavy" for such a simple thing as running a second version of Inkscape, but I think there's no other way. Also, if I would use a tablet for instance, I wonder how easy it would be to get it to work in a virtual machine. Last time I installed one was a few years ago and I remember it wasn't always obvious to get access to all hardware the same way a normal (non-virtual) machine does. But it is definitely feasible, and very low (or zero) risk of borking my system. Good idea.

Concerning compiling: as long as dependencies are met with the other packages and libs already on my system, I have no problem with compiling an Inkscape version. But if I would need to install unstable versions of general libs and packages, that means trouble. Basically the same problem reoccurs: new, unstable libs etc. would (in most cases) replace the existing (stable) ones, instead of being able to exist side by side. Turning my whole system into an unstable one.

Which brings us again to virtual machines, I think. It seems to me that this is the only solution that's easy to implement, very low risk and easy to remove again also if needed.

(Or a live USB, but that's even further from being "side by side" then a virtual machine).

Xav wrote:Well I installed multiple versions by downloading the .deb file from the PPA site then extracting the contents (.deb files are xz archives - google for "extract deb" for details of how to do it). Then I was able to run the binary file in the extracted "bin" folder in my home directory.

As I noted, however, it still tries to use some system-wide files which could cause compatibility issues. Depending on how different the test versions are from your main installed version, this could cause significant problems.

I would not recommend to do this with stable Inkscape 0.91 and unstable Inkscape 0.91+devel (aka trunk): mostly due to the (on-going) internal resolution change in trunk (90dpi -> 96dpi), several of the shared resources installed into "$PREFIX/share/inkscape" have been updated in current trunk and are not or only partially compatible with those from older stable releases (this goes beyond “missing icons”).

bartovan wrote:Chroot and containers are definitely not something I want to, or am able to, venture into. That's over my head.

I decided to give the chroot approach a try, and it's surprisingly simple. There are a few different ways to set up a chroot environment, but the simplest I found was to use the instructions at the bottom of this page.

It requires you to have an ISO of a suitable Linux distro on your machine, which it then unpacks and uses as the source of the files for the chroot. Although I run Linux Mint, I happened to have a Lubuntu 14.04.1 ISO on my machine, so decided to try that. These were the steps I had to perform (using /srv/chroot as the location of my chroot installation, and with the ISO on my desktop). Note that the last two lines (sudo uck-remaster-unpack-iso... are actually a single line command):



That set it all up. It took a few minutes - but faster than compiling Inkscape To enter the chroot run this:



Once inside the chroot I did the following to add the Inkscape-trunk PPA to the system, install the trunk build of Inkscape, and run it (bear in mind that you get put into the chroot as the root user, so there's no need for sudo):



You need to enter the "HOME=/root" line each time you enter the chroot, otherwise your HOME environmental variable will still be pointing to your real home directory - which isn't available within the chroot. After that you can run most things as you would expect by launching them from the command line - remember to append a "&" to the end (as I've done with Inkscape in the example above) to launch them in the background, freeing your terminal to launch other things. If you forget the "&" then press CTRL-z in the terminal to suspend ("stop") the application, then run "bg" to resume it in the background.

Finally, when you're done in your chroot, quit everything then press CTRL-d (or run "exit") in the terminal to return back to your normal, un-chrooted environment.


All in all this was a lot easier to set up than I expected, so it's probably worth giving it a try. As usual it's easier to do than to describe.


Edit: Added some clarification about the very long probably-wrapped line actually being just one line, not two.

OK, interesting.
Is there any practical advantage, now you have set this up, compared to a virtual machine? From a user perspective I mean...

It's a lot more lightweight. I just have to run one command and I'm in the chroot jail within seconds, rather than waiting for a VM to boot up. There's also no CPU or memory overhead beyond what you would get from running the applications directly on the normal OS. Accessing the drive happens directly, not via an extra virtualisation layer. That all adds up to makes it a lot less resource intensive than running a VM.

The other thing is that it's using my existing X server, so not only is there no overhead of running a second X session in a VM, but any applications just run alongside the "native" windows in your main X process. No need for a full screen VM, or some sort of "seamless" hack. No need for guest additions or drivers to get the clipboard to work. I can't test a graphics tablet at the moment, but I reckon that will just work as well (assuming it just works on your native system), without having to set up a USB or serial passthrough.

Of course what you end up with isn't directly comparable to a VM. With this particular approach you end up in the chroot as the root user, not as a "normal" user. And without a local X server running I'm not getting a full Lubuntu desktop experience. A VM is better if you want to try out other Linux distros.

Think of it as just running another copy of Inkscape on your normal machine, but in a way that restricts the directories it can access. I guess that makes it a closer match to your original query.


For some testing a full VM might be better. Do you need to test using a much newer version of Linux than the one on your machine? Then a VM is probably the way to go, as a chroot jail will just be using the kernel, X server and various other bits from your existing system. But if you just want a way to fire up a different version of Inkscape on your current OS, the fact that it's so much more lightweight means there's a lot more memory and CPU left to actually run the program.

Nice!
So, basically, if I understand correctly, you have a new directory in which a full-blown linux distro lives (jailed to this directory). To enter this jailed Linux distro, you open a terminal and do

Whatever you do next in that terminal, is actually happening in your jailed Linux, parallel to your main Linux. And they share the same X server.
And if you want to get rid of the whole thing one day, you just delete the whole directory and that's it, nothing has changed whatsoever in your main Linux. That's really interesting.

The only thing you don't have in there is a window manager, right? I mean, you can't access the programs you installed in the jailed Linux through a graphical interface, you have to fire them up through the command-line.

Would it work if you would install and start up (by command-line inside the jailed linux) a window manager (say Openbox)? And start "inkscape testing" (or whatever you installed there) from this window manager?

This would then be like a kind of super-light-weight VM, no? One could think of a simple startup-script that would contain:
- a line to enter the jailed Linux (uck-remaster-chroot-rootfs)
- the "HOME=/root" line
- a line to start the window manager
and you would have a window manager popping up which would represent your jailed Linux?

bartovan wrote:So, basically, if I understand correctly, you have a new directory in which a full-blown linux distro lives (jailed to this directory). To enter this jailed Linux distro, you open a terminal and do

Code: Select all

sudo uck-remaster-chroot-rootfs /path/to/chroot/directory/

Whatever you do next in that terminal, is actually happening in your jailed Linux, parallel to your main Linux. And they share the same X server.
And if you want to get rid of the whole thing one day, you just delete the whole directory and that's it, nothing has changed whatsoever in your main Linux. That's really interesting.

Yes, that's about the size of it.

bartovan wrote:The only thing you don't have in there is a window manager, right? I mean, you can't access the programs you installed in the jailed Linux through a graphical interface, you have to fire them up through the command-line.

I don't think you really mean window manager, but rather an application launcher. X applications you launch just use your normal window manager and appear alongside other windows on your taskbar. I'm not sure how well the system would take to having a second window manager launched in the same X session, and as I'm on my work machine I can't really experiment to find out!

What I think you're asking for is a way to launch them via a graphical interface. There are third party launchers available that you could install, but at the simplest level you could just symlink the executables to a common directory, then open a file manager pointing at that location. E.g. with Lubuntu, which uses PCManFM as its file manager, I was able to do the following:



I could then launch Inkscape by double-clicking the icon in the graphical window. It wasn't perfect, as I was then prompted for whether to run it or not, but I'm sure with a bit of research you could put .desktop files or simple shell scripts into a common directory to get the right effect.

If you really want a full desktop with its own launcher and window manager, I'm sure there's a solution to be had with XNest or Xephyr - but then it's not so lightweight any more.

bartovan wrote:This would then be like a kind of super-light-weight VM, no? One could think of a simple startup-script that would contain:
- a line to enter the jailed Linux (uck-remaster-chroot-rootfs)
- the "HOME=/root" line
- a line to start the window manager
and you would have a window manager popping up which would represent your jailed Linux?

It's more complex than having a single simple script to do that. The line to start the jail runs in one context (outside the jail), whereas the rest has to run in another (inside it). The normal tricks for running a shell script automatically by having a .bashrc file or similar in your home directory won't work because, until you've run "HOME=/root", your HOME environment variable points at a directory that doesn't exist in the jail. You could modify the chroot's system files in /etc to kickstart things though, such that launching the chroot would then set up the rest.

If you want to run a full graphical desktop then you might be better off with a VM. A chroot jail is a lightweight way of restricting what an application can access, and although you could puff it up with its own X server, launcher, window manager and whatever else takes your fancy, you would rapidly get to the point where you're trying to get a full Linux desktop to run in an environment that's not really meant for that.

OK, so basically it works, but only command-line (unless you get in so deep that you're better off with a VM). Which is fine. Interesting solution.

bartovan wrote:OK, so basically it works, but only command-line (unless you get in so deep that you're better off with a VM). Which is fine. Interesting solution.

That's not quite what I said. It starts with a command line, but then so does every Linux box You could easily set it up to automatically launch some GUI stuff when you start it, but I don't see much advantage in installing multiple GUI programs into a single chroot jail, rather than one jail for each.

In other words, I would set up separate jails for each version of Inkscape you want to test, and modify the /etc/bash.bashrc in each one, adding these lines (or similar) to the bottom:



Back in your main system you can set up aliases or shell scripts to launch each chroot with a simple command, or a double-click on an icon. So if you type "sudo inkscape-test" it would run your script to start the appropriate jail, the /etc/bash.bashrc file in that jail would then launch Inkscape, and you're up and testing.

The chroot isn't limited to command line stuff, it's simply that there's nothing much to be gained in trying to treat it as a full-blown desktop. You've already got one of those. Unless there's a good reason to be limiting a program's access to the filesystem, there's no real benefit in running it in a chroot jail. Testing different versions of Inkscape is a good reason, running a whole extra desktop probably isn't.

Great, thanks a lot for all this
Would be material for the Inkscape FAQ, no?

I don't think it should go in the FAQ for a few reasons:

• Anyone who is serious about testing Inkscape with a view to reporting bugs would be better off compiling from scratch, to avoid reporting "bugs" that are just a result of running in a chroot.
• It's not really an Inkscape thing, so much as a Linux thing.
• The technique I used required you to be using Ubuntu or a derivative. Using a chroot on other distros requires different steps.
• I can count on one finger how frequently this question has been asked

As to that last point: UCK is the "Ubuntu Customisation Kit", and is a suite of tools to allow you to create your own custom Ubuntu CD. Part of that process is the creation of the chroot, so that you can add and remove files and applications before you roll it all up into a bootable image. I've just used it as a simple way to get a chroot up and running, but it's not the only way, or necessarily the "best" if you really want to play around with chroots.

OK. For the UAQ then ? (Unfrequently asked questions)

Xav wrote:I don't think it should go in the FAQ for a few reasons:

• Anyone who is serious about testing Inkscape with a view to reporting bugs would be better off compiling from scratch, to avoid reporting "bugs" that are just a result of running in a chroot.
• It's not really an Inkscape thing, so much as a Linux thing.
• The technique I used required you to be using Ubuntu or a derivative. Using a chroot on other distros requires different steps.
• I can count on one finger how frequently this question has been asked

So, if I understand what I've read here -- Most Linux users who want more than 1 version installed have to compile the 2nd and subsequent versions?

I'm interested in this, because I'm moving ever closer to trying to use some Linux version myself. Especially with the rumors I've heard that Windows/MS will be moving to some sort of cloud-based operating system, ending the era (for MS) of operating systems which are entirely under the user's control; I may have to make the move sooner than just someday. (I've heard that Win10 will be the last of the MS operating systems that reside entirely on the users computer.) So to retain my own (100%) control over my own machine, I'm thinking I may have to move to Linux....assuming Linux isn't going to follow suit.

Note that I probably did not use entirely correct terminology in that explanation. But that's how I currently understand it.