Your message dated Wed, 24 Jul 2019 13:37:32 +0200 with message-id <[email protected]> and subject line Re: Bug#932884: release.debian.org: What is the good way to update rollup ? has caused the Debian Bug report #932884, regarding release.debian.org: What is the good way to update rollup ? to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 932884: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932884 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: release.debian.org Severity: normal Hi all, For the next release, we (pkg-js team) would like to update rollup. Like many compilers, it build-depends on itself. Current version in Buster is 0.50.0, The last published upstream is 1.17.0. We would also like to provide a Buster-backports package Here are the upgrade constraints: * 0.50.0 can build any version until 0.53.3 * 0.51.7 can build any version until 0.56.3 * 0.56.1 can build any version until 0.65.2 * 0.58.1 can build any version until 0.67.2 * 0.59.1 can build any version until 1.12.0 * 1.12.0 can build any version until 1.17.0 This needs 6 steps (at least 4 to be able to update some important JS component with rollup 0.67.2). There are no major break changes in rollup. At worst some function name changed, easy to patch. ====== MAIN QUESTION ====== Is it recommended or required to provide a Buster-buildable rollup package for next release ? ==== IF NO ==== Then we will simply update rollup step by step but there could be problems with Buster-Backports? ==== IF YES, SECONDARY QUESTION ==== What is the best way to provide a Buster buildable package ? In both solutions proposed, there could be buildd/autopkgtest regressions, easy to repair however. == ALL-IN-ONE PACKAGE == This could be possible by embedding 6 or 4 versions of rollup in source package (as component) and build in 6 or 4 steps in debian/rules: override_dh_auto_build: ... # Step N cd step[N]; \ ls -s ../../step[N-1] node_modules/rollup; \ rollup -c ... # Last step ln -s ../step[Last] node_modules/rollup rollup -c Regression fixes: patch rollup configuration file == MULTIPLE PACKAGES == We can provide several rollup packages that build-depends on the previous (rollup-0.52, rollup-0.67,...) with "alternative" mechanism, then rollup becomes a virtual package. Regression fixes: replace rollup build dependency by the good one: rollup-0.67,... * * * Cheers, Xavier
--- End Message ---
--- Begin Message ---Le 24/07/2019 à 13:23, Paul Gevers a écrit : > Hi Xavier, > > On 24-07-2019 09:07, Xavier Guimard wrote: >> For the next release, we (pkg-js team) would like to update rollup. Like > ^^^^^^^^^^^^ > You're talking about bullseye here, or the first point release of > buster. I assume you mean the former. I was talking about bullseye ;-) >> many compilers, it build-depends on itself. Current version in Buster is >> 0.50.0, The last published upstream is 1.17.0. >> We would also like to provide a Buster-backports package >> >> Here are the upgrade constraints: >> >> * 0.50.0 can build any version until 0.53.3 >> * 0.51.7 can build any version until 0.56.3 >> * 0.56.1 can build any version until 0.65.2 >> * 0.58.1 can build any version until 0.67.2 >> * 0.59.1 can build any version until 1.12.0 >> * 1.12.0 can build any version until 1.17.0 >> >> This needs 6 steps (at least 4 to be able to update some important JS >> component with rollup 0.67.2). >> >> There are no major break changes in rollup. At worst some function name >> changed, easy to patch. >> >> ====== MAIN QUESTION ====== >> >> Is it recommended or required to provide a Buster-buildable rollup >> package for next release ? > > I don't believe this requirement exist, nor is it a recommendation. If > there is security risks in this package (I haven't heard them before) it > would be a slight advantage I guess. OK, then it's more simple for us, just to update gradually. There is perhaps another solution to avoid this circular (build) dependency: use node "experimental modules" to build rollup directly from ES6 sources, then no need to convert source to CommonJS using previous rollup >> ==== IF NO ==== >> >> Then we will simply update rollup step by step but there could be >> problems with Buster-Backports? > > Why? I may be missing something, but why are you not just going step by > step. First step one in unstable, wait for migration to testing, upload > to backports and do step two. It takes some time, but it doesn't need > coordination with anybody. Thanks a lot for your response Cheers, Xavier
--- End Message ---
