MultiMC version: N/A (The relevant version of the Debian package is 1.4-1)
Operating System: Debian Sid/Unstable
The qt5-default package that MultiMC depends on is being removed after a long time of packages in the Debian/Ubuntu archive already not being allowed to depend on it. The MultiMC package will soon be uninstallable with Debian 11 and Ubuntu 21.04, and it already is uninstallable with Debian Sid/Unstable.
MultiMC also recommends the openjdk-8-jre package which is bad practice, and won't work at all in Debian which has deprecated it outside of unstable. Similarly, Ubuntu is only carrying it in the universe repo (as a consequence of inheriting its packages from Debian Unstable) so it lacks Canonical support.
The MultiMC package should depend on the specific Qt libraries it requires, instead of qt5-default. As far as I can tell, this should just be libqt5widgets5 libqt5gui5 libqt5network5 libqt5core5a libqt5xml5 libqt5concurrent5
It should also recommend the default-jre package instead of openjdk-8-jre. This points to the Java runtime recommended for the user's distro version and CPU architecture, which will usually be Java 11 on Debian 10+ or Ubuntu 18.04+ (which should still be compatible with any recent Minecraft/Forge/Fabric version), or Java 8 on Debian <9 or Ubuntu <16.04.
Install an instance of Debian Unstable (instructions).
Download the 1.4-1 version of the MultiMC .deb package.
Attempt to install.
openjdk-8-jre is recommended due to Forge and other mods requiring Java 8. In addition Minecraft still comes packaged with that version by default so while vanilla does work with Minecraft there is always the possibility of unexpected behavior.
Dropping java 8 support basically equals dropping modded minecraft support (especially backward compatibility). (Most modpacks are made for minecraft 1.12.*) Debian/Ubuntu might wanna overthink that, given Minecaft is one of the biggest games in existence and openjdk java 8 is AFAIK still maintained.
Otherwise users of those distros will need to download and install java from adoptopenjdk or similar.
Java 11 works fine for Forge 1.15+ so incompatibility will be less and less of a problem with time presumably. My understanding is that vanilla Minecraft also does officially support all newer Java versions, even though it comes bundled with Java 8 (judging by this Dinnerbone comment).
Still, if it's too early to recommend Java 11 now, that's totally cool and it might be fine in a year or so. Keeping the Java 8 dependency will be fine as long as the package is only targeting Ubuntu since it'll stick around in Ubuntu as long as Debian Unstable carries it, and Debian Unstable will carry it as long as it's necessary to bootstrap Kotlin.
I guess at the end of the day as long as we are supporting current Forge by default it should be ok and people could download Java 8 via another distribution. Either getting the archive from Oracle directly or using AdoptOpenJDK instead.
Also it might be possible that issues with older Forge is due to the LaunchWrapper being used. Apparently the default one typically included didn't support past Java 8 but there is another one that does that the Optifine dev started including back in 2018.
https://github.com/sp614x/optifine/issues/1376#issuecomment-417884401
You're essentially stating that old minecraft versions are not a thing anymore.
This is obviously wrong, lots of people still play the old versions.
Forking launchwrapper sounds illegal, that thing is all rights reserved, also, I heard of the fork breaking compatibility of optifine with multimc without using a modloader like forge or fabric.
Debian should consider not breaking compatibility.
OpenJDK 11 is a poorly packaged, poorly built, mess. It's affected by compiler bugs and I cannot recommend its use on any distribution in its current form.
It's absolutely fine to keep the Java 8 dependency for now if devs think that would be best. I think the Qt issue is lot more imperative anyhow.
This is an issue with debian sid; qt5-default installed from buster conflicts with the QT5 GLES-enabled libraries that are now in live sid repositories. I need to use the generic installation for the time being instead of using the deb package.
The GLES-enabled Qt5 libraries are optional variants, the regular packages are still there and work as before. qt5-default has been removed from the Debian archive entirely in any branch newer than Buster and it's normal for it to be removed on upgrade. The current .deb package does work fine if it's manually repacked with a change to depend on the specific Qt5 libraries instead of qt5-default, so it's not an issue with Debian Sid.
Most helpful comment
The GLES-enabled Qt5 libraries are optional variants, the regular packages are still there and work as before.
qt5-defaulthas been removed from the Debian archive entirely in any branch newer than Buster and it's normal for it to be removed on upgrade. The current .deb package does work fine if it's manually repacked with a change to depend on the specific Qt5 libraries instead ofqt5-default, so it's not an issue with Debian Sid.