Announcing Patchmanager 3.2.0: now with 64-bit Transmogrifier

[nephros]

“Ahoi, pirate sailors!”

The Patchmanager dev team (@vlagged, @olf, and myself) is thrilled to be able to announce the new 3.2.0 release of Patchmanager, the tool that allows you to safely apply modifications to your system other people have created for you.

Release Highlights:

L10N: This new version integrates various updates to translations that were missing in 3.1.1, along with improvements of the UI language in a couple of places.

Service Restart UI: We now bring a bit more clarity in the “Restart Services” screen, where we now list which apps or system components will be restarted. So you know whether it’s just the Messages app, or the whole Homescreen (killing all apps)

Automatic conversion of patches: But we also have introduced an important new feature: conversion of patches originally written for 32-bit (or 64-bit) systems to a format that applies to the current users’ system.
These kinds of patches currently fail to apply, which this new release now tries to resolve.
The technical details are below if you’re interested.

To enable this feature, go into Patchmanager’s Settings and tick the “Convert Patches between 32 bit and 64 bit” option.

Because it is new, despite our thorough testing we regard it as a bit experimental still, so please report any issues or other feedback with it (or with anything else patchmanager) here or at Github.

Patchmanager 3.2.0 is available at scurvy peddlers down at the docks as well as from repositories near you at both Openrepos and Chum.

[nephros]

The 32/64bit patch issue:

The issue: The introduction of 64-bit version of SailfishOS came with changes in the filesystem locations of certain files, which are now different on 32-bit and 64-bit systems.
As the majority of patches available were written with 32-bit locations in mind, they now would fail to apply in the newer 64-bit world, because they wouldn’t find the files they were supposed to patch.
Conversely, patches written for a 64-bit system have the same problem with 32-bit systems.

How we tackled it: So we were facing a decision: We could simply acknowledge the fact and advise patch developers to release two versions of their patches. But that is unlikely to work well for several reasons, from not everybody having a 64-bit system to test with, to older, working but unmaintained patches, to unwieldy lists in our Web Catalog.

But it turns out the file locations that may cause the problem are rather predictable, and patch files are actually just text, so they can be changed.
And this is what Patchmanager 3.2.0 does now.

Before actually applying a patch, PM will scan it for locations which are known to be different between systems, and if it finds some, it rewrites the patch file accordingly before it applies it.
This happens completely transparently to the user (and even the original patch developer) who don’t need to care or know about any of it.

Technical details
We now keep a configurable list of file locations that will be scanned for and changed on demand. You can look at it and change it in the file /etc/patchmanager/manglelist.conf, the source of which lives here.

But please, if you find that there is a location missing from the current list, let us know in an issue report so we can add it.

Why the list and not just convert anything under /usr/lib to /usr/lib64? Well, /usr/lib exists on 64-bit systems as well and patches might want to do something in both. So we maintain the curated list, depending on users and developers to notify us of missing locations.