<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 22 mars 2019 à 15:51, Jonas Smedegaard <<a href="mailto:jonas@jones.dk">jonas@jones.dk</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Quoting Jérémy Lal (2019-03-22 14:54:07)<br>
> it takes some time to understand what's happening here, and since <br>
> fixing it properly will require quite some work on multiple packages, <br>
> i add my notes to this bug report.<br>
<br>
I fail to recognize your description below of the situation and how it <br>
involves "quite some work" to solve.</blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Did you see my description at <a href="https://bugs.debian.org/924807#28" rel="noreferrer" target="_blank">https://bugs.debian.org/924807#28</a> ?<br></blockquote><div><br></div><div>Yes, changing the dependency on uglifyjs to node-uglify of all concerned</div><div>packages. Doing so without regressions will require quite some work.</div><div><br></div><div>The other solution - migrate all packages to uglifyjs 3 - requires a lot more work.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> # Situation<br>
> Because uglify version 2 compiles software that uglify version 3 does <br>
> not compile correctly, and vice-versa,<br>
<br>
No (unless I am missing out on some information), the difference is not <br>
correctness of processing but difference in API (when linked with other <br>
NodeJS libraries) and ABI (when using certain command-line options).<br></blockquote><div><br></div><div>Indeed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> there are two versions in debian:<br>
> * uglifyjs-2.8.29 builds node-uglify which provides uglifyjs<br>
> * uglify-js-3.4.9 builds uglifyjs<br>
<br>
Correct.<br>
<br>
<br>
> # Solutions (in my order of preference, to be adapted)<br>
> 1. Packages not building with uglifyjs 2 should be fixed to build with<br>
> uglifyjs 3.<br>
> Not a trivial thing to do and it's deep freeze now.<br>
<br>
[ assuming you mean "...now building..." ] </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
That is certainly the long-term plan, because only v3 is actively <br>
maintained.<br>
<br>
Repackaging should however not be needed urgently, as v2 and v3 should <br>
generally coexist fine. </blockquote><div><br></div><div>My turn to not understand:</div><div>many packages not coinstallable due to a conflict is fine ?</div><div>node-uglify conflicts with node-uglify-js.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Only cases where both ends up attempted used <br>
together need urgent fixing.<br></blockquote><div><br></div><div>Sure, that needs urgent fixing.</div><div><br></div><div>However, debian users developing websites will typically want to use</div><div>webpack and uglifyjs. And currently in Buster they won't be able to install</div><div>both, and likewise with many other packages.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 2. Distribute /usr/bin/uglifyjsN and fix all packages calling<br>
> /usr/bin/uglifyjs to call<br>
> uglifyjsN, when they can't be fixed to use latest version of<br>
> /usr/bin/uglifyjs.<br>
> <br>
> # Slight improvement that might be done for buster<br>
> IF apt behaves like i think it will, to allow both /usr/bin/uglifyjs and<br>
> node-uglify<br>
> package to be installed:<br>
> * uglify-js-3.4.9 builds node-uglify-js which provides uglifyjs and<br>
> conflicts uglifyjs (<< 3.5.0-2),<br>
> and remove uglifyjs binary package (to get it to be pure virtual package).<br>
> <br>
> However, if dependencies both try to install node-uglify and node-uglify-js<br>
> it will still fail,<br>
> but it's not as bad as a direct conflict with /usr/bin/uglifyjs.<br>
> It could be misleading, though, to have an unexpected version, so maybe the<br>
> best thing<br>
> is to do nothing for Buster.<br>
<br>
Sorry, I am lost on what you propose here - especially the short-term <br>
part.  Can you perhaps provide some concrete examples of packages that <br>
are broken now and are solved by... what exact change, for Buster?<br></blockquote><div><br></div><div>The proposed change is to switch back uglifyjs to a pure virtual package, as it was before,</div><div>(if what i know about apt is right) that would solve the main example above: install webpack + uglifyjs.</div><div><br></div><div>I do care to avoid further mess and i understand that no change shall be made on a hurry,</div><div>it is just something i wanted to discuss.</div><div><br></div><div>Jérémy<br>
</div><div><br></div></div></div></div>