Dear Jolla Team, please add bash as standard shell again into SFOS.
In the meanwhile (NO WARRANTY!):
As root download “gnu-bash” with pkcon. Deinstall busybox-symlinks-bash forcely.
Install gnu-bash-5.0.18+git1-1.2.1.jolla.armv7hl.rpm with rpm manually.
The result will be - working custom scripts again.
Version:
# bash -version|head -1
GNU bash, version 5.0.18(1)-release (armv7l-unknown-linux-gnueabi)
Conflicting packages
# ls -1 *rpm
busybox-symlinks-bash-1.31.0+git17-1.3.5.jolla.armv7hl.rpm
gnu-bash-5.0.18+git1-1.2.1.jolla.armv7hl.rpm
@ced117, this is not mistake, it is a positive consequence of a nice strategy change at Jolla:
As denoted in the IRC community meeting logs, they ceased to avoid GPLv3 software in general.
Instead they started distributing GPLv3 software as optional RPMs for SailfishOS, i.e. what formerly was (until SailfishOS 2.2.1) in the mer-tools repository. Now (since SailfishOS 4) only the RPMs for the basic SailfishOS (i.e., which may be installed by default) are still kept free of GPLv3 software.
This change in strategy allowed Jolla to update the historic, last GPLv2 version of bash (v3.2.57) to a recent bash v5, but only as an optional RPM. At the same time a recent busybox version of ash is installed by default, along with a symlink which calls ash in its (limited) bash compatibility mode.
RPMs at Openreps can simply conflict to busybox-symlink-bash in their spec file and bash will be automatically installed, if it was not installed before. But preferably their shell scripts shall be freed of BASHisms.
Users can simply uninstall the busybox-symlink-bash RPM and bash will be installed, if it was not installed before. Users not capable of accomplishing that do definitely not need a bash for interactive use.
TL;DR
While this may break some apps for now, it is easy to adapt them.
Much more importantly, Jolla’s license strategy change is a small, but relevant step forward for Jolla and SailfishOS.
This is arguable: on one side, FREEdom; on the other side, more industry interest.
Anyhow, if I understand correctly the change here is not “the core system has become GPL3-free”; it is "the core system is still GPL3-free, but now it is easier to install GPL3 apps because you don’t need to add repos.
My understanding is similar to what @fph stated above: GPLv3 has some additional restrictions related to commercial use cases that GPLv2 doesn’t have. Eventhough they have similar names, these additions in GPLv3 leads to you not being able to mix and match GPLv2 and GPLv3 code/libs/tools in same project. I assume these commercial restrictions might risk Jolla’s commercial operating model and they want to keep the core elements GPLv2.
The mix could be the problem. One can not mix GPL2 and GPL3. I am involved in GPL2 project FreeCAD. We do no include GPL3 software, because than we would need to relicense everything on GPL3. That might be the reason for GPL3 free Sailfish core too.
Maybe inside a single project, but most Linux distros include both GPL2 software (case in point: the kernel, git) and GPL3 software (case in point: modern versions of bash) and nothing exploded; so that alone is not the reason.
Do I understand it correctly? Recap: from SFOS3.4 to SFOS4.0 the bash package was updated from version 3 (GPLv2) to version 5 (GPLv3). And that is the reason why bash can not be in the compose of the SFOS flashable image? My understanding is that if a projects “binds” to the GPLv3 licensed software, then the problems arise (linking, shared opbjects etc). https://www.gnu.org/licenses/gpl-3.0-standalone.html#section1
but thats not the case for SFOS/bash. SFOS already proved with SFOS4 that can run without bash. So including it like other distros should not be a problem.
The Business customers of Jolla have a different opinion and they bring in the most money. In the meeting-log I remember reading that not having GPL3 software in the base image will lead to more paying customers. I think the meeting log was quite clear on 08:06:31.
I do understand that reality is not always like we want it to be. I am very happy that for some software there is now a way forward. I prefer this situation over staying stuck on bash v3. Packages that really need it can still have it as a dependency.
Haven’t tested but I would assume just plain pkcon remove busybox-symlinks-bash should do the trick. If it says gives some error and lists the package name with exact version, try again with the exact name and it probably works this time.
By my own experience, busybox ash scripts are running without problem in gnu bash but not viceversa. Therfore gnu bash should be considered a super-set in terms of scripting capabilites compared to near complete busybox ash.
Because of this, reverting back the default shell to gnu bash should not create - presumably - no any problem unless very peculiar corner cases are triggered. However, those applications that need gnu bash should call it expressely:
scripts: with the proper shebang #/bin/bash or #/usr/bin/env bash
executable: forking or childing with /bin/bash
However, this sane approch fails if the busybox or a package installed in /bin/bash a link to busybox executable. This should be considered a mistake, in any system that can potentially host the gnu bash or it for which with gnu bash was a long-term referencing shell interpreter.
Thus regression is a correctly chosen word in the title of this post, IMHO.
Issues related to qCommand found on 4.5.0.19
Creating an icon for executing a command, it happens that:
the command spawn an opening application that stays on the home screen much longer the comand completed when the command complete almost immediately and sucessfully even if kill -9 $$ or kill -9 $PPID has been added at the end. Probably is about a timeout in the apps launcher.
a command icon created by qCommand cannot be deleted as any other application, Moreover, it is not possible to remove it even if the original script in qCommand is deleted but this makes sense because I may want remove the command without removing the icon, and viceversa.
I hope this helps, R-
UPDATE
I add the suggestion to restore the /bin/bash symlink to the original bash shell in my quick start guide in hints and tips section.
I believe that is because for .desktop files of Type=Application, Lipstick tries to use PackageKit to find the owning package of the .desktop file, and then uninstall that package.
That obviously can’t work for qCommand-created files because they are not owned by anything.
One way around that would be to create an RPM package on the fly which owns the created files.
HOWEVER that’s more or less illegal because rpms must never own files located in $HOME (because that can cause issues with updates, and in other ways).
That’s not true, it’s easy to remove both the script and the .desktop file. Not using a native UI though (although it could be done e.g. with a GUI file manager).
Pretty much, although it does it via the org.sailfishos.installationhandler DBus interface (see: /usr/share/lipstick-jolla-home-qt5/launcher/Launcher.qml line 337ff)
