[Pkg-mozext-maintainers] tree-style-tab conversion to WebExtensions

Dmitry Smirnov onlyjob at debian.org
Thu Jul 26 05:01:07 BST 2018


On Thursday, 26 July 2018 1:31:00 PM AEST Ximin Luo wrote:
> I'm not sure why you think it's "difficult" to create symlinks at build
> time. Do you need to verify that the symlinks point to valid targets?

Yes, that one of the problems. With systems like dh_link or dh_linktree, 
staged tree always have broken symlinks on build-time because symlinks are 
relative to destination while tree is staged in temporary build directory.

More over, unless we depend on exact package version, installed dependency 
with relationship greater-than may install files into different path and that 
can only be spotted when package is installed.

It is trivial to spot problems with symlinks in extracted addon directory - 
not so easy in zipped archive though. 

Another interesting challenge is how to zip on build time. Suppose I have all 
Depends packages in Build-Depends and I want to compress prepared tree with 
zip. Which target zip command will go to? override_dh_build is too early as 
resulting directory will be staged only by the time build progress to 
dh_install stage, right? Except that dh_link runs after dh_install.
Running zip from override_dh_link (after dh_link) looks very counter-
intuitive...

I've found that zipping Firefox extention bundle on build time is needlessly 
difficult comparing to postinst.

Also keep in mind that that zipped bunndle is like statically linked binary.

It should be easy enough to introduce APT hook to re-compress bundle on 
dependency update comparing to bin-NMU process...


> In general doing stuff in the postinst is bad because it's arbitrary code
> execution as root. In general we'd like to move towards more declarative
> packaging that doesn't involve executing Turing-complete logic. It's safer
> for users, in case there are bugs, and gives less space for developers to
> abuse users' end systems.

You are right, I agree.

Maybe there is a way to avoid that hassle entirely if we can find out how to 
drop Firefox addons caches so uncompressed addons can be reloaded...
Chromium have no problem detecting changes in uncompressed extensions...

-- 
Regards,
 Dmitry Smirnov.

---


Truth — Something somehow discreditable to someone.
        -- H. L. Mencken, 1949
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-mozext-maintainers/attachments/20180726/62711c65/attachment.sig>


More information about the Pkg-mozext-maintainers mailing list