Score:0

How to install a previous version of Gimp with Flatpak on Ubuntu 20.04?

cn flag

I'm on stock Ubuntu 20.04.2, and I have managed to install the latest / current Gimp with Flatpak: it was the 2.10.24 version at the time.

However, there are a few issues with the 2.10 line that I can't seem to be able to resolve.

For this reason, I would like to install Gimp 2.8.

I know that that older Gimp version may rely on an older Python version as well, so installing the whole thing with Flatpak seems to be handy, as it will be standalone (isolated from the OS) and can use its own (older) Python version without any complication at all.

But I can't seem to be able to find out how to even list the currently supported Gimp package versions with Flatpak, let alone installing it.

So please: how can I see which Gimp versions (apart from the most recent one) are installable with Flatpak currently, and how can I install a specific version?

(Also, can it complicate things that I already have another (more recent) Gimp version installed with Flatpak? So, can I have two versions parallel, or would I have to delete the more recent one first in order to install the older one?)


Update:

I have followed the guidance in @wizardpurple's answer, and have found the following:

So now I have run the command:

$ sudo flatpak update --commit=19dcc22b60e69eaaf740d4311021ed55b7e2537d org.gimp.GIMP

But it says:

Looking for updates…

        ID                                        Branch     Op     Remote      Download
 1.     org.freedesktop.Platform.GL.default       20.08      u      flathub     < 100.8 MB
 2.     org.freedesktop.Platform.VAAPI.Intel      20.08      u      flathub      < 11.6 MB
 3.     org.gnome.Platform.Locale                 40         u      flathub     < 333.7 MB (partial)
 4.     org.gtk.Gtk3theme.Yaru-light              3.22       u      flathub     < 203.4 kB
 5.     org.gnome.Platform                        40         u      flathub     < 362.6 MB
 6.     org.gimp.GIMP                             stable     u      flathub     < 117.2 MB

Proceed with these changes to the system installation? [Y/n]:

These appear to be dependencies of the Gimp flatpak. Apparently they are needed for this older Gimp? I already have these installed, due to how Gimp 2.10.24 needed them; are these / some of these also going to be downgraded?

My concern is that while this flatpak ecosystem is indeed isolated from the main OS, it seems that internally it still maintains some dependencies. So I don't know whether I mess up this flatpak ecosystem by downgrading Gimp...


Update 2:

I have run the flatpak update --commit command, and it died as follows:

First it went through all the dependencies without a problem (while it consistently downloaded less data for each of them correspondingly as the download size was up front indicated), then when it reached Gimp, as the last item, it went:

OSTree:ERROR:src/libostree/ostree-core.c:1432:ostree_checksum_inplace_to_bytes: assertion failed: (checksum[j])
Bail out! OSTree:ERROR:src/libostree/ostree-core.c:1432:ostree_checksum_inplace_to_bytes: assertion failed: (checksum[j])
Aborted

Then the OS gave the "System program problem detected" dialog.

I suppose I could submit an issue on the Github repo.

wizardpurple avatar
cn flag
Hmm...I received the same result. It appears the commits listed by ```flatpak remote-info --log flathub PACKAGE_NAME``` are not github commits (though those are partially shown in the output still), but maybe something flathub specific? I will update my answer.
Nate T avatar
it flag
I just checked the same command. Assuming you installed via flathub, there is no 2.8. Only goes back to 2.10.22
Nate T avatar
it flag
If you install via apt, you may be able to use `--package` option (I think that is the syntax, its been awhile.) You may need to search to find a repo with the desired version.
Nate T avatar
it flag
@wizardpurple They are commits to the flathub repo from which end user downloads.
wizardpurple avatar
cn flag
@NateT thanks. It looks like flathub only keeps 10 or so, which makes sense considering flatpaks are meant to be the latest and it could get out of hand quickly. When I tried to view the information about the last entry's parent with ```remote-info --commit=```, it returned a 404.
Nate T avatar
it flag
Makes sense. I know that it is possible to get 2.8 with apt / apt-get, but downgrading with apt (or any pkg mgr) is risky. Sometimes the dependency trail doesn't stop where you want it to. If I werer OP, I'd just use a tarball. He/ she should already have most or all dependencies.
Levente avatar
cn flag
@NateT as I have mentioned in the question, my biggest concern would be the Python dependency. Gimp 2.8 still depends on Python 2, which is these days frowned upon. So if downgrading Gimp would downgrade Ubuntu's OS-wide Python to 2, then I would probably be in big trouble (as you have hinted at the dependency trail not stopping at a convenient point).
Score:1
cn flag

Edited with corrected information. Parts rewritten for clarity.

Summary

The simplest option for running GIMP 2.8 on Ubuntu 20.04 looks to be running it in an Ubuntu 18.04 VM (GNOME Boxes is handy) and installing it through the official repos. There might be the option of trying to build the older flatpak... However, GIMP is a beefy piece of software and building a 2-3 year old flatpak could very well produce its own set of headaches.

Installing older flatpaks versions

You can install older versions of a flatpak by specifying a specific commit to target. Available commits can be found by using the remote-info command. You need to already have the flatpak installed for this to work. The older version takes place of the newer one, since you are performing a downgrade.

The results of remote-info are not a complete history, as there appears to be a cutoff point for versions kept. Because flatpaks are used to make it easy for developers to push the latest versions of software, keeping everything would not be so easy on storage space.

# examine remote
flatpak remote-info --log flathub org.gimp.GIMP

--snip--

    Commit: c53c42d04e88c0b0c416d5b4d3aa7600d1cdbdcd36d051b1af5c4ae980e29bb2
   Subject: Build Little-CMS 2.12 ourselves. (13d146e6)
      Date: 2021-03-29 16:33:51 +0000

--snip--

# install specific commit
# root privileges required for system  
flatpak update --commit=c53c42d04e88c0b0c416d5b4d3aa7600d1cdbdcd36d051b1af5c4ae980e29bb2

# to prevent future updates, you can mask the flatpak
flatpak mask org.gimp.GIMP

The commits from the flatpak remote-info --log command cannot be substituted with the commits from GitHub as I previously thought. The GitHub commits are referenced in the output (13d146e6) in the above example but are not the ones used for moving between versions.

flatpak tips and tricks

'Possibly' Running Multiple Versions

If you wanted the latest gimp and an older version that was available from the remote-info output, you could try installing one as a system package and the other as a user package. Maybe not the most elegant of methods but it should work.

flatpak install flathub org.gimp.GIMP # system/default

# user method also requires adding the flathub repo to the user repos
flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install --user flathub org.gimp.GIMP # user
Levente avatar
cn flag
Wow, that is like, waaay less user-friendly (or even, sensible) that I hoped / expected. I think I should mark the answer accepted only if I tried this out and it worked, but I feel like I need to bring myself into the right mindset and level of focus before I could follow up on this. Until then, please have my +1. And thank you!
Nate T avatar
it flag
If he/she is wanting multiple versions, the best way is just to tarball it, imo. With package mgrs, while it is possible to maintain multiple installs, they will fight you every step of the way. After all, that is their main job. Btw, I think that is the complete history. Pipe it to `more`.
wizardpurple avatar
cn flag
@NateT same results with ```more```. I think there is likely a cutoff point. I was thinking, like your tarball, building the flatpak locally might could work. This way older dependencies remain separate, but I'm not sure how convenient it would be to do. I suspect GNOME Builder could make things smooth but I've never done it. With snap, the resulting .snap file could be installed locally.
Nate T avatar
it flag
Just download the .deb file and install with `sudo dpkg -i <NAME-OF-FILE.deb>`
Nate T avatar
it flag
or for tar.gz just run `tar` or `make`. Tar command is `tar -xzf <NAME-OF-FILE.tar.gz>`
wizardpurple avatar
cn flag
@NateT but gimp 2.8 won't build or install on ubuntu 20.04, in large part because it relies on python 2.7
Nate T avatar
it flag
is python 2 no longer supported? I thought 20.04 had both 2 & 3. I haven't really been keeping up though. I know that `python` runs 3 now, but I thought `python2` ran the other. Although just that change in syntax alone could stop it from working
Levente avatar
cn flag
@NateT As I have hinted at it in my comment on the question itself, I don't see (I won't try) trying to get 2.8 with dpkg. 2.8 would only work if it would be running in a sandboxed/isolated env, like in flatpak's. Don't they have a snap also?
wizardpurple avatar
cn flag
@Levente The snap will only offer the latest version of GIMP. I'm thinking the easiest way to access GIMP 2.8 in Ubuntu 20.04 is through an 18.04 vm
Nate T avatar
it flag
@wizardpurple I will try to install 2.8 on my system via tarball, just to see how well it works. I currently have the snap edge release, which is the newest version available. Ill install 2.8 into `/opt/gimp28/` just to make sure, but I'm 95% sure it will work as long as 2.10 isnt uninstalled via package mgr, as that would likely remove needed dependencies.
Nelson avatar
mx flag
`flatpak update --commit` command needs the app id (org.gimp.GIMP) at the end, otherwise it will fail. I submitted an edition to the answer in that regard.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.