[Pkg-javascript-devel] acorn 8

[Jonas Smedegaard]

Quoting Xavier (2020-10-11 17:24:46)
> 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

The I apologize: I misread your post as directed more broadly at the 
whole Javascript team.


> >> 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

I reacted to this:

> our usage of virtual names in build dependencies make dak blind


> > 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

No, ftpmaster policy may force us to stuff multiple source projects 
together, but does not force us to declare package relations for such 
combi-packages in ways that violate Debian Policy.

Debian Policy dictates that a build-dependency must be deterministic - 
which means it is fine to build-depend on a virtual package but only if 
ensured that only one instance of that package is available at any time.

Example: It is fine to build-depend on libz-dev

I don't know what actual problems you experience (you haven't shared 
details, and I prefer that you do so in bugreports instead of here), so 
I am only guessing that above could be one possible cause of trouble.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-javascript-devel/attachments/20201011/1afed521/attachment.sig>