Wouldn’t using the Flatpak solve both these issues. Stay on a commit, mask the update. 
I don’t see making an RC available as an option to users as a bad thing – especially if it can hasten the removal of Python 2 in Fedora Linux. This has been long overdue, it would be much more than just nice if we could spare the Python SIG from maintaining it beyond the 5 year anniversary of its upstream end of life.
It’s not as if the switch to “3.0.0” will somehow make any lingering bugs vanish.
Thanks! It would be sufficient to have 256x256 PNGs, I can simply scale them down to the other sizes when building the package.
1 Like
Again, there are some issues with GIMP in Flatpak and third party plugins – I don’t think you can build plugins against gimp-devel headers from a Flatpak for instance.
2 Likes
There is some precedent to making the RC of a package part of the Fedora release, and shipping the final slightly before or slightly after the Fedora release (simply because schedules don’t always align perfectly). However, it should be noted, that many of those precedents are for packages that tend to follow a rather well defined and mostly time limited RC schedule (such that the RC stage might not linger for quite some time). Given that the original target of May 2024 clearly was missed, what is the current estimate (by the Gimp core developers) as to the new target date (there still appear to be a few dozen release blockers, but I don’t know how many are waivable, nor how many require significant additional work).
1 Like
that one is included, and a 64x64 and some others. The SVG can be scaled from within Inkscape export
1 Like
NB, this is the string/API freeze target which just might not yet be checked off in the timeline. The RC target, which is “May/June”, could theoretically still be held – though I wouldn’t bet anything valuable on it.
Historically, and I believe this time it isn’t different, the GIMP developers are reluctant to give time estimates – they’re clearly not time-boxing things (like we do, or GNOME). Their “3.0 RC1” milestone expires on Jul 31, 2024, however.
I’d say if an RC is available by the time of our beta freeze and the bugs left to fix on the final milestone are tolerable, then it makes the way free to remove GIMP 2 in Fedora 41 (and move it to COPR if there’s demand).
1 Like
I am not new to Fedora, but I often default to installing apps using dnf because I’m odd that way. I use GIMP regularly, but for lightly-duty work related to my programming work. I am not a GIMP follower at all, so I was completely unaware that some major new version was on the horizon. So, if not for this thread, I would be one person who would be installing GIMP from the command line and getting an older version, if indeed that is how it is going to work. It does sound less than optimal if true.
3 Likes
Let me attempt to clarify this: gimp is version 2 in Fedora Linux ≤ 40 and not a meta package, installing it in a current stable release gives you the old version and this won’t change. Optionally, you can install gimp3 (once it’s out of testing or you have the updates-testing repo enabled) which right now is the 2.99.18 pre-release. In Fedora Linux 41 and supposing GIMP 3 progresses as I hope, gimp would become a meta package depending on gimp3 and GIMP version 2 would become gimp2[1]. I would make it so upgrading would pull in both versions if gimp2 is available during the upgrade[2].
I hope this addresses your concerns.
4 Likes
If it worked like that, then yes that would be ok for my usage pattern. I mistakenly understood that “gimp” would continue to install GIMP 2 whereas “gimp3” would be required to run the newer version on future releases.
This change proposal has now been submitted to FESCo with ticket #3233 for voting.
To find out more, please visit our Changes Policy documentation.
1 Like
I’ve updated the original proposal to implement changes asked by FESCo. In summary:
- GIMP 2.x won’t be available in Fedora Linux 41+ as an RPM package
- This is to unblock Python 2.7 from finally being retired
I tried to update the text of the proposal here with the changes from the wiki page, but couldn’t – probably because it was created in the course of the Change Process and not by myself originally. It’s probably better for me to wait on the FESCo verdict on my updated proposal anyway 
.
3 Likes
@nphilipp I plan to retire python2.7 in rawhide (Fedora 42) after branching and to keep it around in Fedora 41 waiting for GIMP 3 RC.
The retirement will break the gimp package in Fedora 42 unless it is updated to 3. Is this something you could do in Fedora 42 even before the RC is out?
2 Likes
This change has been accepted by FESCo for Fedora Linux 41. A full list of approved changes to date can be found on the Change Set Page.
To find out more about how our changes policy works, please visit our docs site.
2 Likes
Do you mean: after F41 is branched off, fold gimp3 content into the gimp package so we would have 2.99.18 or a git snapshot or an RC (depending on availability)? I can’t think why not.
OK. I’ll retire python2.7 right after branching then.
2 Likes
In light of the finalised conclusion relating to GIMP 2 and Python 2, I wonder if the system upgrade to F41 will merge gimp and gimp3 packages when both are installed on a F40 system?
I have both installed. I stopped using GIMP 2 when GIMP 3 actually ran smoother on my system (F40 KDE Plasma). I’ll just remove gimp (v2) before upgrading to F41, but there might be users that have both packages at the time of performing system upgrade.
Perhaps you already accounted for this possibility.
I have friends who really aren’t technical people, that use dnf for searching for and installing apps (to my (positive) surprise). One of which is gen z. I was even asked to compile a cheatsheet list of useful commands and they actually use it.
I’ve converted both friends and family to Fedora, many of which aren’t technical people. While some use Discover, others use dnf and say they prefer it as it’s quicker (which it is) and I applaud them for it.
Regarding finding apps in GUI repo browsers to be installed via dnf as described by @tqcharm in this comment, I couldn’t agree more.
Sometimes I send people commands to run, sometimes for apps I don’t use myself and I think it’s only reasonable to assume that the name of the app corresponds with the package name viadnf (and provides the latest version). I’ll quickly run the command on my system without confirming, just to see if it correspond with a package, before sending it to someone. I don’t think it’s resonable to expect anyone to investigate or check for inconsistencies in dnf compared to “KDE Discover” or “GNOME Software”, or inconsistencies with the app name (package names commonly lack version and just provides the latest version, as is the most intuitive). 
I also don’t think we should assume that only technical and “advanced users” use CLI utilities and thus assume they’ll just figure things out (advanced users benefit from consistency and intuitive behaviour too). I think that if one is to assume that dnf is for advanced users only, it’ll risk becoming less user-friendly as a result, for both advanced users and beginners alike.
A major reason for me recommending Fedora, specifically, is dnf. It’s intuitive to use, unlike e.g. Pacman which requires an upper case “S” (lower case won’t work) for what would be “install” in dnf, just to give one example.
There’s also the use of set-up scripts and online guides (which aren’t updated to reflect packaging changes). I would never guess (or expect) that the “gimp” package would get a new name.
Personally, I exclusively use dnf and think CLI tools are a major strength of Linux (also for non-techies). Even though many people already use GUI solutions and many newcomers will too, I’d argue it’s beneficial to encourage beginners to give command-line a chance and not assume beginners aren’t relevant. “Advanced” and “user friendly” can and often do go hand in hand.
1 Like
It should, the gimp package in F41 will (implicitly) upgrade itself from older Fedora versions, and it explicitly obsoletes the gimp3 package.
There should be no need for it, the upgrade should pull gimp (the current snapshot pre version 3/RC) right back in and replace gimp3 (if it is installed).
4 Likes