pminstaller 0.1.5 does not install shell script

[Kriton]

I just updated to palemoon 24.7.1 using pminstaller 0.1.5. I noticed that the last line in the progress report said that a link was created from /usr/bin/palemoon to /opt/palemooon/palemoon. Sure enough, /usr/bin/palemoon was no longer a shell script.

This means that with the default palemoon installation, palemoon will be unable to find the installed plugins. Make sure you keep a copy of /usr/bin/palemoon, before upgrading, or use pminstaller 0.1.4, to upgrade.

[access2godzilla]

It was done very much on purpose, as /opt/palemoon/palemoon would be directly invoked in some cases instead of /usr/bin/palemoon.

Exporting MOZ_PLUGIN_PATH in /etc/profile should do what you want. (Now I wonder why I put a shell script in the installer).

[Kriton]

It was done very much on purpose, as /opt/palemoon/palemoon would be directly invoked in some cases instead of /usr/bin/palemoon.

I noticed this myself, as well; I believe I managed to figure out where this was configured, and changed it. Unfortunately, I then forgot all about it, so I can't tell you where it was!

Given that distributions don't know about pale moon, isn't pale moon somehow responsible for having configured the system to use /opt/palemoon/palemoon in some cases?

Exporting MOZ_PLUGIN_PATH in /etc/profile should do what you want.

Modifying a configuration file, unrelated to an application, sounds like a bad idea. At the very least, this will cause problems when the distribution is updated, and /etc/profile is overwritten, which could be as frequent as twice a year; frequent enough to be a problem, infrequent enough to make many people forget all about it.

Pminstaller 0.1.5 creates pale moon installations where plugins do not work, giving no indication that the user should do something about it. I think this will deter people from adopting pale moon for Linux, as they might think that it is broken.

(Now I wonder why I put a shell script in the installer).

Perhaps because other distributions use the same approach? Fedora, e.g., starts firefox using a much more complicated shell script than pale moon's.

How about making /opt/palemoon/palemoon a shell script that invokes the actual executable? This would fix all problems: /usr/bin/palemoon could remain a link, and running /usr/bin/palemoon or /opt/palemoon/palemoon would not result in a different behavior for the browser.

[access2godzilla]

Could you do the following for me (I'm AFK, sorry):
- Make a clean PM install.
- Invoke /opt/palemoon/palemoon-bin
- Set PM as default when it asks you to do so.
- cat ~/.local/share/applications/userapp-Pale\ Moon*.desktop

[Kriton]

Oddly enough, I just logged in to mention that the file you mentioned is most likely the one I edited, to correct the association!

I'll try your suggestion in a couple of hours in a Fedora VM I have at work, where Pale Moon is not installed. This should make it a really clean installation, without any leftovers from a previous one.

(The reason I didn't mention it, when I edited the file, was that I thought that this was one such leftover.)

[Kriton]

Code: Select all

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
NoDisplay=true
Exec=/opt/palemoon/palemoon %u
Name=Pale Moon
Comment=Custom definition for Pale Moon

[access2godzilla]

I'll look into what can be done, but unfortunately there doesn't seem to be an easier way than mucking with the source.