packaging extensions for multiple applications

XZS · 2015-05-13 11:53:30

I am currently trying to package Mozilla extensions like Stylish that can be used with many different applications. To use them with Firefox for example, its files have to be placed into a directory in /usr/lib/firefox/browser/extensions. To use it as a Thunderbird add-on, the exact same files have to go to /usr/lib/thunderbird/extensions. To avoid redundancy, my PKGBUILD symlinks one to the other.

But I am unsure about how to express the dependencies. The add-ons only work with a small range of host application versions. In the depends array, I could do something like "thunderbird>25" "thunderbird<27" but placing Thunderbird and Firefox in depends is clearly wrong because the plugin can work with one of them without the other one installed. Optdepends are better suited, but unable to include version restrictions.

I thought of creating a split package instead.

mozilla-extension-stylish contains the files itself and depends on nothing.
firefox-extension-stylish contains only the symlink into the Firefox extension directory and depends on mozilla-extension-stylish and firefox
thunderbird-extension-stylish contains only the symlink into the Thunderbird extension directory and depends on mozilla-extension-stylish and thunderbird

But I have the feeling that I am overly complicating things a little here.

What is the correct way to define the dependencies of a plug-in that can run with multiple host applications?

ANOKNUSA · 2015-05-13 12:11:10

But I have the feeling that I am overly complicating things a little here.

Well, when you say Mozilla extensions "like Stylish," are you just using Stylish as an example? Because anyone can install that in Firefox/Thunderbird itself. It's already been packaged and publicly available for a very long time, and can be installed with a single mouse click. I've had it installed for years. It would be interesting to know if the other extensions you plan to package aren't also available elsewhere, and why users can't just download them there. In my opinion packaging easily obtained plugins like this is the digital equivalent of sending a note for your roommate from your living room to your kitchen in a cubic-meter box via UPS, instead of just walking over and handing it to them.

Lone_Wolf · 2015-05-13 12:17:11

OP may be wanting to have the extension available for all users, like the firefox-noscript package.

XZS, i'd go with a split package also.

ANOKNUSA · 2015-05-13 12:24:44

Lone_Wolf wrote:

OP may be wanting to have the extension available for all users...

Firefox extensions are installed and enabled at the user lever. The only step a package would save is the actual installation, which (again) requires a single mouse click versus typing out pacman commands. And installing a theme manager like Stylish system-wide seems pointless, since most users are unlikely to use it or know it even exists. These are the reasons I'm asking.

helix · 2015-05-13 15:17:59

Optional dependencies CAN have versions restrictions if you want

XZS · 2015-05-13 18:36:38

helix wrote:

Optional dependencies CAN have versions restrictions if you want

It seems they can, but are then ignored. This can be demonstrated a small PKGBUILD.

pkgname=optdpends
pkgver=1
pkgrel=1
arch=(any)
optdepends=('bash>10: for testing')

Installing the resulting package and running

pacman -Qi optdepends

tells

Optional Deps  : bash>10: for testing [installed]

which is impossible as bash is currently at version 4.*.

Also, I assume, when restricting to a version range, the dependency will show up twice.

Optional Deps  : bash>2: for testing
                 bash<10: for testing

But perhaps I am just missing a detail on how to specify them correctly?

ANOKNUSA wrote:

It would be interesting to know if the other extensions you plan to package aren't also available elsewhere, and why users can't just download them there.

All of them are available via Mozilla's Add-On directory, apart from their git variants, of course. However, many of them are also available in the AUR.

There are actually some valid reasons to manage such extensions using pacman.

For users very accustomed to the command line, typing yaourt -S mozilla-extension-stylish; firefox may actually be more intuitive than browsing to addons.mozilla.org, searching for the extension there, clicking install and restart Firefox. For Thunderbird this is even more of a hassle as extensions have to be installed from a downloaded file.
The package manager is the central facility to install and update all software. Some users prefer to also manage extensions there instead of using about:addons for Firefox extensions, The Edit>Preferences window for Thunderbird extensions, Gnome Tweak Tool for GNOME Shell extensions, and so forth. A single yaourt -Syu then updates not only Firefox, but also all its extensions.
As Lone_Wolf already pointed out, it makes sense to install the extension globally when many different users have it activated. Apart from saving space this also eliminates the need for each user to update their copy of the extension themselves.
As mentioned in my first post, packaging makes it easier have just one instance installed for use in multiple applications.

Evidently, this does not mean that everyone should only use pacman to install Firefox Add-Ons on Arch Linux, but it is nice to have the choice. The question whether to install such things via pacman vs. using the host application sure would be worth a large discussion, which we should continue in a dedicated thread.

Last edited by XZS (2015-05-13 20:19:22)

helix · 2015-05-13 20:03:42

Of cource they are ignored. that's why they are called OPTIONAL dependencies. They work mostly as info for users about what packages could enhance the usability of package X.

Scimmia · 2015-05-13 20:25:08

XZS wrote:

helix wrote:
Optional dependencies CAN have versions restrictions if you want
It seems they can, but are then ignored. This can be demonstrated a small PKGBUILD.
pkgname=optdpends
pkgver=1
pkgrel=1
arch=(any)
optdepends=('bash>10: for testing')
Installing the resulting package and running
pacman -Qi optdepends
tells
Optional Deps  : bash>10: for testing [installed]
which is impossible as bash is currently at version 4.*.
Also, I assume, when restricting to a version range, the dependency will show up twice.
Optional Deps  : bash>2: for testing
                 bash<10: for testing
But perhaps I am just missing a detail on how to specify them correctly?

That looks like a pacman bug. A pretty insignificant one, but still a bug.

XZS · 2015-05-13 20:26:30

The term "ignored" is indeed unclear. I wondered about the line

Optional Deps  : bash>10: for testing [installed]

which I read as: "This package optionally depends on bash version greater than 10, which is installed". This is in fact wrong, as bash is installed only in version 4.* . I expected it to be

Optional Deps  : bash>10: for testing

to tell me that "this package has optional functionality which becomes available as soon as a bash version greater than 10 would be installed."

Is this a bug in pacman or am I specifying the optdepends wrong?

XZS · 2015-05-13 20:31:13

Scimmia answered faster than I could ask. I will file this in the pacman bug tracker.

Still, how shall a version range be specified? Neither

optdepends=('bash<10: for testing' 'bash>2: for testing')

nor

optdepends=('bash<10' 'bash>2: for testing')

looks quite right.

Scimmia · 2015-05-13 20:35:15

Dep ranges usually require two entries, so your first example is correct.

Arch Linux

#1 2015-05-13 11:53:30

packaging extensions for multiple applications

#2 2015-05-13 12:11:10

Re: packaging extensions for multiple applications

#3 2015-05-13 12:17:11

Re: packaging extensions for multiple applications

#4 2015-05-13 12:24:44

Re: packaging extensions for multiple applications

#5 2015-05-13 15:17:59

Re: packaging extensions for multiple applications

#6 2015-05-13 18:36:38

Re: packaging extensions for multiple applications

#7 2015-05-13 20:03:42

Re: packaging extensions for multiple applications

#8 2015-05-13 20:25:08

Re: packaging extensions for multiple applications

#9 2015-05-13 20:26:30

Re: packaging extensions for multiple applications

#10 2015-05-13 20:31:13

Re: packaging extensions for multiple applications

#11 2015-05-13 20:35:15

Re: packaging extensions for multiple applications

Board footer