[Pkg-javascript-devel] Bug#925211: Bug#925211: uglifyjs conflicts with webpack which can hinder JS maintainers work

Jérémy Lal kapouer at melix.org
Fri Mar 22 15:22:43 GMT 2019


Le ven. 22 mars 2019 à 15:51, Jonas Smedegaard <jonas at jones.dk> a écrit :

> Quoting Jérémy Lal (2019-03-22 14:54:07)
> > it takes some time to understand what's happening here, and since
> > fixing it properly will require quite some work on multiple packages,
> > i add my notes to this bug report.
>
> I fail to recognize your description below of the situation and how it
> involves "quite some work" to solve.


Did you see my description at https://bugs.debian.org/924807#28 ?
>

Yes, changing the dependency on uglifyjs to node-uglify of all concerned
packages. Doing so without regressions will require quite some work.

The other solution - migrate all packages to uglifyjs 3 - requires a lot
more work.

> # Situation
> > Because uglify version 2 compiles software that uglify version 3 does
> > not compile correctly, and vice-versa,
>
> No (unless I am missing out on some information), the difference is not
> correctness of processing but difference in API (when linked with other
> NodeJS libraries) and ABI (when using certain command-line options).
>

Indeed.


> > there are two versions in debian:
> > * uglifyjs-2.8.29 builds node-uglify which provides uglifyjs
> > * uglify-js-3.4.9 builds uglifyjs
>
> Correct.
>
>
> > # Solutions (in my order of preference, to be adapted)
> > 1. Packages not building with uglifyjs 2 should be fixed to build with
> > uglifyjs 3.
> > Not a trivial thing to do and it's deep freeze now.
>
> [ assuming you mean "...now building..." ]


> That is certainly the long-term plan, because only v3 is actively
> maintained.
>
> Repackaging should however not be needed urgently, as v2 and v3 should
> generally coexist fine.


My turn to not understand:
many packages not coinstallable due to a conflict is fine ?
node-uglify conflicts with node-uglify-js.



> Only cases where both ends up attempted used
> together need urgent fixing.
>

Sure, that needs urgent fixing.

However, debian users developing websites will typically want to use
webpack and uglifyjs. And currently in Buster they won't be able to install
both, and likewise with many other packages.

> 2. Distribute /usr/bin/uglifyjsN and fix all packages calling
> > /usr/bin/uglifyjs to call
> > uglifyjsN, when they can't be fixed to use latest version of
> > /usr/bin/uglifyjs.
> >
> > # Slight improvement that might be done for buster
> > IF apt behaves like i think it will, to allow both /usr/bin/uglifyjs and
> > node-uglify
> > package to be installed:
> > * uglify-js-3.4.9 builds node-uglify-js which provides uglifyjs and
> > conflicts uglifyjs (<< 3.5.0-2),
> > and remove uglifyjs binary package (to get it to be pure virtual
> package).
> >
> > However, if dependencies both try to install node-uglify and
> node-uglify-js
> > it will still fail,
> > but it's not as bad as a direct conflict with /usr/bin/uglifyjs.
> > It could be misleading, though, to have an unexpected version, so maybe
> the
> > best thing
> > is to do nothing for Buster.
>
> Sorry, I am lost on what you propose here - especially the short-term
> part.  Can you perhaps provide some concrete examples of packages that
> are broken now and are solved by... what exact change, for Buster?
>

The proposed change is to switch back uglifyjs to a pure virtual package,
as it was before,
(if what i know about apt is right) that would solve the main example
above: install webpack + uglifyjs.

I do care to avoid further mess and i understand that no change shall be
made on a hurry,
it is just something i wanted to discuss.

Jérémy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-javascript-devel/attachments/20190322/973913d3/attachment.html>


More information about the Pkg-javascript-devel mailing list