Sebastian Noack:
> [..] the only thing that install-xpi seems to do is creating symlinks in
> /usr/share/mozilla/extensions/ based on the supported applications listed
> in install.rdf. But WebExtensions should not have an install.rdf, and
> support exactly one Gecko application (i.e. Firefox). So while xpi-pack and
> install-xpi seem useless for WebExtensions, what might still make sense are
> the ${xpi:*} substitutions in the control file, but the minimum/maximum
> Gecko version would have to be extracted from manifest.json instead of
> install.rdf.

Is it really the case that a webext only supports one application? Where is 
this documented, and how is it detected by the application itself (to check 

>>> However, it is much simpler, and probably not any less appropriate
>>> than relying on deprecated mechanisms, to simple use debian/install
>>> and debian/links files, in order to achieve the same result, as I did
>>> here [2].

I think it's best to have a debhelper "--with webext --buildsystem webext" to 
standardise this, just to maintain some consistency across different packages, 
and to avoid newbies getting confused. I'll have a go at doing this in 

Perhaps we can have a debian/install-webext file to list the $applications, to 
install symlinks under /usr/share/$applications/extensions/.

Did you test your own [2] under Debian's chromium? I thought Chromium does not 
support unpacked system webextensions, and in fact a bug I filed a few years 
ago for this, was recently rejected:

>>> But I wonder whether this is the way how Firefox extensions are
>>> supposed to be packaged in the future. Otherwise, mozilla-devscripts
>>> would have to be updated, in order to support WebExtensions properly,
>>> unless I miss something.
>>> Also I wonder whether it still makes sense to package Firefox and
>>> Chromium extensions separately, if the the only difference is either a
>>> symlink in /usr/share/mozilla/extensions/ or a script with one line in
>>> /etc/chromium.d.
>> Thank you for these suggestions. It would be great if Firefox and
>> Chrome addons could just be under a webextension-* namespace.
> FWIW, I'd rather go for the abbreviation "webext-" as this consistent,
> both, with the old "xul-ext-" prefix, and with the "webext" W3C group which
> standardizes these. But this is just bikeshedding, I suppose.

I also support unifying this under a webext- prefix.

> Anyway, this generally seems to be a good idea, though there are some more
> things to think about:
> * Where should cross-browser extensions be installed in the filesystem?
> * What is about extensions that will remain only compatible with either
> Chromium or Firefox?
> * What is about extensions that support both browsers, but with different
> builds?

I took a look at your [2] and the paths seem OK IMO. I'll submit a proposal for 
updating mozilla-devscripts soon. (Eventually we could rename this to 


Sebastian Noack:
> [1]:
> [2]:

GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE

Pkg-mozext-maintainers mailing list

Reply via email to