Dropping 32bit Rust

[lazka]

@workingjubilee approached us yesterday in chat asking if it would be a problem if upstream rust would drop "i686-pc-windows-gnu"

I'm preparing an RFC with a peer, but basically we have a lot of problems because

• no one tests the target enough
• no one contributes enough maintenance to it
• the people who do maintain it are already doing a lot and this is like their quaternary thing after also helping out with more general windows support
• we don't even have many downloads for it
  

@ognevny and @1480c1 came out in support of dropping 32bit rust.

Looking at https://packages.msys2.org/packages/mingw-w64-i686-rust we have:

• libimagequant
• libdovi
• rav1e
• librsvg

The first three we can look into dropping right away I think, for librsvg I'll ask GIMP devs again what their status on gimp2 releases will be in the future. @Jehan

If we want to keep librsvg for longer we could just copy the current rust PKGBUILD and keep the current rust version for mingw32, which should work as long as llvm and MSRV play along.

[workingjubilee]

you'll have at least a few months to figure out what the story will be for librsvg, as the very fastest possible turnaround for us deciding to Officially drop it going forward will be in Rust 1.87 (and I expect it may take a bit more hemming and hawwing). nonetheless your enthusiasm for the update is appreciated. :^)

[lazka]

good to know, thanks

[Jehan]

I'll ask GIMP devs again what their status on gimp2 releases will be in the future. @Jehan

GIMP 2 should not be a problem since we should have GIMP 3 released by then. But this is about 32-bit support, so even GIMP 3 is concerned. Right now our Windows installer is a universal x86/x86_64/AArch64 installer (though our MSIX build which is brand new is x86_64/AArch64 only).

I think (i.e. if I recall correctly) that we wanted to have at least a few releases of GIMP 3 with x86 build so that people can at least get a somewhat early version of GIMP 3 at their disposal even if we were to drop this architecture later on.
I.e. that even if people would not have updates (and worse: security updates) anyway — so their situation is definitely not good —, they would at least have some reasonably modern version of GIMP (GTK3, Python3, Wayland support, etc.).

@brunvonlope Was that the last state of our discussions? Does Jernej also have an account on Github by the way?

Personally I wished we would not basically deprecate a whole range of perfectly working hardware (which will end up in trash at some point when it will have no update whatsoever from any software), but I know I can't fight against this current. Even less all by myself. Ecologically this is a shame. But I am powerless here. 🤷

[brunvonlope]

Was that the last state of our discussions?

@Jehan The actual status is the same, it was decided to move from 32-bit TWAIN to 64-bit WIA 2.0 only after 3.0, and that partly depends on MSYS2/MingW/Wine guys(?): #17451.

Does Jernej also have an account on Github by the way?

I think Jernej isn't involved with this at all. Wormnest gently offered himself to do it when it have time but, again, only after 3.0.

---

All that being said, things are escalating from MSYS2 to another projects so I wouldn't be against to revisit our decision and drop 32-bit sooner (the decision I linked mentions many reasons for that). The problem is that we don't know how many people use TWAIN scanning and that can be very disrupting.

[brunvonlope]

By the way, we have 7K active users of our preview MSIX (https://apps.microsoft.com/detail/9nzvdvp54jmr?hl=pt-BR&gl=BR) and no one complained yet about the lack of 32-bit TWAIN.

[ognevny]

librsvg is the only one remaining rdep now :)

[lazka]

ok, let's wait a bit with librsvg then. If something changes we'll post it here.

[Jehan]

GIMP3 could be built without librsvg, It will just use raster (.png) icons instead of vector (svg) ones.

Officially, no. We still need librsvg at build time when using raster icons (to create the icons).

And the SVG plug-ins still needs librsvg at runtime. For the latter, it is easy to patch GIMP to not include the SVG plug-in. But it's not an official option because we consider SVG too important as a format (even for a raster manipulation software) to call it optional.

So officially, no it's not possible to ignore librsvg.

Unofficially, you can, but (1) it's still needed at build time anyway and (2) it needs a very small one-liner patch, but a patch anyway.

[lazka]

gtk requires svg for loading symbolic icons, and gimp requires it for loading svg, so I don't see how that is an option.

[Jehan]

I maintain GIMP and I've been taking care of this librsvg issue myself for years now (because we have other issues with it, some people just don't like Rust and have been complaining about this dependency for some time now). So yes, when I'm saying that librsvg is required at buildtime, I am sure of it. Or something changed behind my back (it didn't!).

librsvg is needed:

1. For our SVG plug-in: this is both build and run times. And this is not an option. Yet as I was saying, it can easily be patched out (removing these lines), which is not something we recommend and would make this build a non-supported non-vanilla build.
2. For core code, if you set -Dvector-icons=false (what you did in your link!), then our build would install PNG icons instead of SVG ones. Therefore if you also patched out the SVG plug-in, in this case, librsvg is not needed anymore at runtime, but it definitely stays needed at buildtime because… we use librsvg to convert said SVG icons to PNG!

Therefore yes: I confirm and it's not something in question: officially librsvg is definitely needed both at build and runtime. Unofficially, you could easily make it non-needed at runtime with some patching, but it'd still be needed at buildtime. So you'd have to jump some hoops.

[workingjubilee]

An important note is that even if the proposal to downgrade the target is accepted, Rust will likely maintain some support for building for this target. The main difference is that it won't be "first-class" anymore.

Most compilers have tiered support policies, but unlike other compilers, which have policies that allow some pretty... ad-hoc decisionmaking about what support means when it comes time to do a release... Rust defines "tier 1" to have a very specific meaning: "guaranteed to work". So we have an extremely strict policy of running tests for all tier 1 targets before merging anything. That's why having such a "jank" target as tier 1 causes us so many problems.

Of course, this also means we won't be in a rush to fix stuff if the library stops working, because tier 2 is only "guaranteed to build". So I'd usually recommend always cross-building the code from an actual tier 1 host.