<div dir="auto">Hi Sean<br><br>On Fri, May 12, 2017 at 10:33 PM, Sean Whitton <<a href="mailto:spwhitton@spwhitton.name" target="_blank">spwhitton@spwhitton.name</a>> wrote:<br>><br>> Dear Sebastian,<br>><br>> On Thu, May 11, 2017 at 02:29:35PM +0200, Sebastian Noack wrote:<br>> > as you might know, Firefox is moving away from traditional Gecko<br>> > extensions, towards WebExtensions which are essentially the same as<br>> > Chrome extensions.<br>><br>> Right.  We need to update our tools, but the work hasn't started yet.[1]<br><br>As far as I understand, the only thing that xpi-pack does, besides creating an XPI file (which essentially is just a standard ZIP file), is some magic for unpacked JAR files within, which is no longer relevant for WebExtensions. Moreover, creating an XPI/ZIP file, just to have it unpacked by install-xpi seems redundant in the first place. Besides that, 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.<br><br>> > WebExtensions don't need an install.rdf manifest. In fact the<br>> > documentation indicates that is has been deprecated as part of legacy<br>> > extensions [1]. Still, I would have to create an install.rdf, just so<br>> > that I can use install-xpi.<br>> ><br>> > However, it is much simpler, and probably not any less appropriate<br>> > than relying on deprecated mechanisms, to simple use debian/install<br>> > and debian/links files, in order to achieve the same result, as I did<br>> > here [2].<br>> ><br>> > But I wonder whether this is the way how Firefox extensions are<br>> > supposed to be packaged in the future. Otherwise, mozilla-devscripts<br>> > would have to be updated, in order to support WebExtensions properly,<br>> > unless I miss something.<br>> ><br>> > Also I wonder whether it still makes sense to package Firefox and<br>> > Chromium extensions separately, if the the only difference is either a<br>> > symlink in /usr/share/mozilla/extensions/ or a script with one line in<br>> > /etc/chromium.d.<br>><br>> Thank you for these suggestions.  It would be great if Firefox and<br>> Chrome addons could just be under a webextension-* namespace.<br><br>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.<div dir="auto"><br></div><div dir="auto">Anyway, this generally seems to be a good idea, though there are some more things to think about:</div><div dir="auto"><br></div><div dir="auto">* Where should cross-browser extensions be installed in the filesystem?</div><div dir="auto">* What is about extensions that will remain only compatible with either Chromium or Firefox?</div><div dir="auto">* What is about extensions that support both browsers, but with different builds?<div dir="auto"><br>> I think the best thing might be to have a meeting about this with any<br>> pkg-mozext people at Deb[Camp|Conf], to figure out a transition plan.<br><br></div><div dir="auto">That sounds like a good idea and/or perhaps we could loop somebody of them in on the discussion here.</div><div dir="auto"><br></div><div dir="auto">Sebastian</div></div></div>