Bug#932884: release.debian.org: What is the good way to update rollup ?
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
Reply to: