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 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
