[Pkg-javascript-devel] acorn 8

[Xavier]

Le 11/10/2020 à 13:00, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-10-11 10:39:44)
>> I fixed node-promise and rollup. Now acorn 8 seems ready for unstable.
>>
>> Unless someone disagrees, I'm planing to push it to unstable.
> 
> What are you really asking?

I'd simply like to have @rouca agreement

> If you mean to imply that you have checked all reverse dependencies and 
> reverse build-dependencies, and none of them fail with the new version, 
> then I see no problem (and see no need for you to ask).

I checked and fixed all reverse dependencies I found (see below)

> If instead you mean to imply that you have *not* checked all reverse 
> dependencies and build-dependencies and ask others to do that task, then 
> I find it (perfectly fine that you ask, but) unacceptable that you ask 
> so vaguely: Please explicitly say so, if you are requesting others to 
> some tasks.

I'm not sure to have tested all. Anyway, I didn't found problems related
to acorn 8 itself but other bugs not seen previously:
 * node-resolve: distinct problem
 * rollup: bad rollup-plugin-commonjs parameter

The main breaking change with acorn 8 concerns /usr/bin/acorn which
requires now ECMA version to check.

> Ideally, file bugreports for each such task - but I do recognize that 
> both checking for problems and reporting each problem are tasks too.
> 
> 
>> However, our usage of virtual names in build dependencies make dak 
>> blind: only 2 packages (rollup and babel8) use the real package name 
>> (node-debbundle-acorn). Others use one of its virtual names, then all 
>> Debian tools can't find real reverse dependencies (ruby-team/meta, 
>> dak, reverse-depends,...). So I'd like to add this in our policy: 
>> "never use a virtual dependency in build dependencies unless it is 
>> known by cme".
> 
> I don't like that proposal.
> 
> I do not use cme, and I don't want my work in the Javascript team to 
> require me to use that spcific tool or have intimate knowledge on what 
> that specific tool does or does not handle.

I was talking about cme, but we can simply use its
ignored-virtual-package-list

> Such failures to detect relationships seems like issues we should track. 
> Maybe issues with each of those tools not obeying Debian Policy, or 
> maybe it turns out to be issues with how relationships are declared 
> being not Policy compliant.
> 
> Are there already bugs files for these issues?  If not, could you please 
> file bugs about it, so we can track each of them?

A virtual package can be provided by more than one package. The problem
comes from our virtual package use (due to ftpmaster policy...). Anyway,
we can try to open BTS