Re: kind of special transition for luajit{,2}?
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 <pkg-games-devel@lists.alioth.debian.org>
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 <pkg-games-devel@lists.alioth.debian.org>
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.
Reply to: