[Pkg-javascript-devel] Bug#962039: Bug#962037: Plan B for not being able to replicate upstream exports exactly

[Pirate Praveen]

On Sun, Jun 14, 2020 at 9:33 pm, Daniel Ring <dring at wolfishly.me> wrote:
> There are several different issues in this bug, I'll address each of 
> them individually (identified by message date as shown in the BTS for 
> bug 962037):
> 
> 
> Date: Tue, 02 Jun 2020 16:30:29 +0530
> 
> I unfortunately don't have the time to regularly test package 
> versions in experimental. Javascript development moves very quickly 
> and packages often change their APIs with each new version, many of 
> which don't even make it to unstable. The issue will likely be 
> resolved by updating the bundled version of gulp-less.

I did not ask you to test with every package in experimental. The idea 
is to give you a warning that less.js will soon come to untsable and 
you can be ready with the required changes before that. This is a 
standard practice (transitions) when uploading breaking changes. In 
this case, you were asked to test a specific package in experimental 
after I verified your package breaks with the new version (and no other 
package breaks). If you prefer not to be notified in advance for 
breaking changes, I'd be happy to ignore rainloop for any future 
transitions. You will still get a chance to fix when someone files an 
FTBFS bug against rainloop.

> Date: Tue, 02 Jun 2020 16:30:29 +0530
> 
> Please don't bundle dependencies or dependencies of dependencies 
> unless absolutely necessary, and if you must then only include the 
> required files. The Rainloop package is bloated enough due to 
> upstream bundling as it is. It appears that pkg-js-tools bundling 
> doesn't handle this, so I didn't use it. The version numbers of the 
> packages I bundled are included in a comment at the top of each file, 
> but I had to modify most of them to remove dependencies not in Debian 
> (and not required for Rainloop to build), so they can't be trivially 
> updated

Please don't invent your own methods and follow the standards used by 
the rest of the team. If everyone invents their own methods to embed, 
that makes it unnecessarily hard to collaborate as a team. I don't 
think the rest of the js team agrees with your judgement here. This 
method makes is harder to update embedded dependencies and it 
essentially become a fork. You can use the normal patching workflow 
with quilt for modules embedded via pkg-js-tools (it is not even 
specific to pkg-js-tools, it is supported by dpkg and used across the 
archive).

Js Team,

Please comment your opinion here as we have a difference in embed 
strategy here.

> 
> The dependencies I bundled are all build tools pinned to specific 
> versions by upstream, so updates to them aren't particularly 
> significant. Any bundled dependency important enough for its version 
> number to be tracked should be made into its own package instead. 
> Let's not build a new package management system on top of the 
> existing one just to dodge the NEW queue.
> 

No, we did not build this by choice. It was proposed and pushed by ftp 
masters to reduce the number of node packages in the archive. Many 
packages in NEW were rejected already because they were too small. 
https://wiki.debian.org/Javascript/Nodejs/NEW So for node packages, 
only complex dependencies are expected to be packaged separately. So 
you are completely wrong here to assert the idea is to dodge the NEW 
queue.
> 
> Date: Tue, 02 Jun 2020 16:52:33 +0530
> 
> This message appears to be meant for the less.js fork of the bug.
> 
> 
> Date: Tue, 02 Jun 2020 18:56:26 +0530
> 
> It is not maintainable to call lessc directly instead of using 
> gulp-less. I created a custom Makefile to build Rainloop in the first 
> version of this package, but it was unmaintainable; the upstream 
> build process changes slightly with each release, and I would have to 
> relearn and rewrite my Debian-specific hacks each time. That's why I 
> switched to using upstream's build system directly and bundling the 
> handful of missing Gulp modules in the latest release.
> 
> 
> Date: Tue, 02 Jun 2020 22:33:01 +0530
> Date: Wed, 03 Jun 2020 00:29:58 +0530
> 
> These messages appear to be related to issues with less.js, not 
> Rainloop.
> 
> 
> Date: Wed, 03 Jun 2020 01:27:35 +0530
> Date: Fri, 05 Jun 2020 11:36:16 +0530
> Date: Fri, 05 Jun 2020 11:54:23 +0530
> 
> The bundled gulp-less version appears to be incompatible with the new 
> version of node-less. I had modified it to work with the outdated 
> version currently in the Debian archive; after reverting the relevant 
> changes, Rainloop now builds with node-less from experimental. Note 
> that the build will be broken in unstable until node-less migrates 
> from experimental.
> 

You don't have to upload broken packages to unstable. You can wait till 
less.js lands in unstable to upload your changes to experimental. The 
idea is to give you a chance to fix your package before it actually 
breaks.

> Date: Fri, 05 Jun 2020 15:10:04 +0530
> Date: Fri, 05 Jun 2020 17:11:12 +0530
> Date: Fri, 05 Jun 2020 21:32:03 +0530
> 
> The node-autolinker package was updated by yadd (Xavier Guimard) a 
> few weeks ago and the path of the Autolinker.js file changed. 
> Updating the path resolved the build error.
> 
> I pushed the fixes for both issues to the Rainloop repository on 
> salsa.d.o. Rainloop now builds successfully on current unstable with 
> node-less from experimental.
> 

Thanks, I can upload it to unstable.

> -- Daniel
> 
> On 6/5/2020 9:02 AM, Pirate Praveen wrote:
>> 
>> 
>> On Fri, Jun 5, 2020 at 5:11 pm, Pirate Praveen 
>> <praveen at onenetbeyond.org> wrote:
>>> 
>>> 
>>> On Fri, Jun 5, 2020 at 3:10 pm, Pirate Praveen 
>>> <praveen at onenetbeyond.org> wrote:
>>>> This is likely broken by node-merge-stream update from 1.0 to 2.0. 
>>>> node-merge-stream is a build dependeny of node-autolinker.
>>> 
>>> Tried building with autolinker 3.x in embed-autolinker-3 branch, 
>>> but the same failure.
>>> 
>>> I tried to run the upstream test suite for node-autolinker (yarnpkg 
>>> install, yarnpkg test), but it seems gulp 3 is segfaulting in 
>>> debian, tried with node 10 and 12 via npm with the same results. 
>>> I had seen the same failure when trying to run gulp in node-puka 
>>> as well.
>> 
>> All unit tests passed on autolinker master which has gulp 4 with 
>> merge-stream 2.0, so it is not merge-stream change that broke.
>> 
>>