On Sat, 2022-06-04 at 08:19 +0200, Paul Gevers wrote: > > > So I uploaded luajit2, which at least passed hello world smoke > > test on IBM arches including ppc64el and s390x. > > https://buildd.debian.org/status/package.php?p=luajit2 > > May I ask what your reason is to have both? Why not replace luajit with > luajit2 and be done with it?
Currently I have no idea whether src:luajit2 can completely replace src:luajit. I plan to keep them both for a while and see. That said, due to the uncooperative fact of the src:luajit upstream, I lean toward removing it once we're confident about the replacement. > > So I changed the dependency template for bin:libluajit-5.1-2 > > You use the word template several times in your message. Do you mean > template in the sense that it's manually applied in all places, or is > there automation involved I'm not aware of? Please see deb-symbols(5), the symbols control file contains a part supporting advanced usage that not all Debian developers know: main-dependency-template | alternative-dependency-template The examples section of deb-symbols(5) is instructive about this feature. More than one of packages I maintain has leveraged such feature (like BLAS alternatives). I can give an extra example to prove this: currently I have a pending commit to change the src:luajit dependency template: https://salsa.debian.org/lua-team/luajit/-/commit/06f74ff251646e159afba9b9a8dc2488ec848a75 We take src:love as example. The current bin:love package has the following dependency: Package: love Version: 11.3-1 Priority: optional Section: games Maintainer: Debian Games Team <[email protected]> Installed-Size: 4,593 kB Depends: libc6 (>= 2.29), libfreetype6 (>= 2.2.1), libgcc-s1 (>= 3.4), libluajit-5.1-2 (>= 2.0.4+dfsg), libmodplug1 (>= 1:0.8.8.5), libmpg123-0 (>= 1.13.7), libogg0 (>= 1.1.4~dfsg), libopenal1 (>= 1.14), libsdl2-2.0-0 (>= 2.0.10), libstdc++6 (>= 5.2), libtheora0 (>= 1.0), libvorbisfile3 (>= 1.1.2), zlib1g (>= 1:1.2.0) Recommends: binfmt-support Then I rebuild it against with the above luajit commit pending to upload: sbuild --no-clean -c sid -d unstable love_11.3-1.dsc --extra-package ../luajit.pkg/ debc love_11.3-1_amd64.changes Package: love Version: 11.3-1 Architecture: amd64 Maintainer: Debian Games Team <[email protected]> Installed-Size: 4521 Depends: libc6 (>= 2.33), libfreetype6 (>= 2.2.1), libgcc-s1 (>= 3.4), libluajit-5.1-2 | libluajit2-5.1-2 (>= 2.0.4+dfsg), libmodplug1 (>= 1:0.8.8.5), libmpg123-0 (>= 1.28.0), libogg0 (>= 1.1.4~dfsg), libopenal1 (>= 1.14), libsdl2-2.0-0 (>= 2.0.12), libstdc++6 (>= 11), libtheora0 (>= 1.0), libvorbisfile3 (>= 1.1.2), zlib1g (>= 1:1.2.0) See the dependency change? Note, there is ZERO change for the src:love package at all. This is a super awesome feature of Debian dependency tree. > > from > > libluajit-5.1-2 > > into > > libluajit-5.1-2 | libluajit2-5.1-2 > > Related to my question of why keep both, why not the reverse order? At the current stage, I'm not completely confident that src:luajit2 can fully replace src:luajit . We can reverse the order in the future, or directly remove src:luajit in the future. > > Since both packages Provides libluajit-5.1.so.* > > > > Thus, this is not a usual transition with ABI bump. I want to > > rebuild all luajit reverse dependencies so that the dependency > > Rebuild, or change source and reupload? Given the above illustration of dependency template, I indeed mean rebuild reverse dependencies without any change of source. > > template for them will be updated. In that case the corresponding > > reverse dependencies can smoothly start to use libluajit2-5.1-2, > > especially for ppc64el architecture. > > If you're not changing the source of all those reverse dependencies, how > does that work? deb-symbols(5). This is a great feature and advanced usage. > > When the rebuild is done, we should be able to safely remove > > ppc64el architecture for src:luajit . > > Well, as I filed RC bugs against all reverse dependencies of src:luajit > to switch their (build-)dependency on ppc64el to lua, we'll be able to > do this shortly anyways. Maybe less work is required given the possibility to change dependency without modifying the code of reverse dependencies? :-) > Paul > PS: I'd rather had it that you'd file a bug already to have this > discussion. It's much easier to track than our high volume mail list as > it keeps the pieces together. OK, understood. I'll later submit a bug pointing at this ML post.
