Bug#1055198: ITP: lzfse -- LZFSE Compression library
* Andreas Henriksson [2023-11-04 23:03]: I hope I understood you correctly and this now adresses your concerns: https://salsa.debian.org/bananas-team/asahi-fwextract/-/commit/bfbd6f53c2e8721b9457c3a37421280a8a86dbc8 Yes, that looks good! I also like the fallback. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1055198: ITP: lzfse -- LZFSE Compression library
Hello, On Sat, Nov 04, 2023 at 08:47:11PM +0100, Timo Röhling wrote: > Hi, > > * Andreas Henriksson [2023-11-04 18:05]: > > I've previously suggested that maybe it would be better to set a > > debian-specific version (0d?), to avoid the theoretical situation that > > upstream one day ships a different ABI under the 1 so version. > Normally, I would agree, but in this particular case, Fedora already went > ahead and used SOVERSION 1 [1], so that version is "burned" and we might > just as well use it, too. > > [1] https://src.fedoraproject.org/rpms/lzfse/blob/rawhide/f/60.patch Thanks for pointing this out! > > > I would welcome peoples input here on what you think is best from the > > debian perspective. Obviously we're going to be incompatible with > > everyone else. > I don't think that "incompatible" patch you linked creates much of an issue, > because very few (if any) other library consumers will do this rather > unusual dlopen() "soft linking" dance (normal linking with e.g. "gcc > -llzfse" will automatically use the proper SONAME); besides, it is easy to > patch in Debian packages and trivial to work around with "apt install > liblzfse-dev" for everyone else. > > I do have one remark, though: the idea behind SONAME/SOVERSION is that you > have a common name for all versions which are binary backwards compatible. > Using the full version liblzfse.so.1.0 instead of libltfse.so.1 (i.e., the > SONAME) in your patch defeats that purpose: it will only work with the exact > version 1.0, but not any (hypothetical) future, backwards-compatible > versions. I hope I understood you correctly and this now adresses your concerns: https://salsa.debian.org/bananas-team/asahi-fwextract/-/commit/bfbd6f53c2e8721b9457c3a37421280a8a86dbc8 Regards, Andreas Henriksson
Bug#1055198: ITP: lzfse -- LZFSE Compression library
On Sat, Nov 04, 2023 at 06:05:41PM +0100, Andreas Henriksson wrote: > On Thu, Nov 02, 2023 at 01:04:03AM +0100, Tobias Heider wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Tobias Heider > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: lzfse > > Version : 1.0 > > Upstream Authors: > > URL : https://github.com/lzfse/lzfse > > * License : BSD-3-Clause > > Description : LZFSE Compression library > > > > LZFSE is a Lempel-Ziv style data compression algorithm using Finite > > State Entropy coding. It targets similar compression rates at higher > > compression and decompression speed compared to deflate using zlib. > > > > I plan to maintain this as part of the bananas team. > > Calling all SO versioning experts! > > The upstream project does not have any shared object version set. > A downstream patch was introduced to set one: > https://salsa.debian.org/bananas-team/lzfse/-/blob/debian/unstable/debian/patches/0001-debian-set-library-SONAME.patch > > Upstream has seen no activity since 2017, so trying to interact is > assumed to not generate much. (sorry, I imagine you are already aware of what I am about to say, but still I think it's worth saying... Apologies if I'm lecturing, I think you may have been a DD longer than I have :)) This... may be a problem. This means that any fixes you have to make (security fixes, important bug fixes, or just improvements that really, really bug your sense of doing things right) will be specific to the Debian package, and unless the other packaging systems pick them up, with time things will diverge further and further. The best thing to do in this case is to - somehow - try to push things in a direction that ultimately leads to the library having active upstream developers. This may mean having you or somebody you know try to contact the current developers and ask to join them. In a close-to-the-extreme version of this, this may mean you (or somebody you know) taking over upstream development with the consent of the current developers. In a really, really extreme version, it may mean forking the project without the consent of the current developers and facing various kinds of weird things down the road, especially if they wake up one day and decide to carry on as usual, ignoring your fork. One thing to note that I have learned from bitter experience: you may feel that it would be fun and it would not be too difficult to take over upstream development, and doing this too many times may lead to a situation that you are the upstream developer for too many things and you cannot really give most of them enough attention. There is no single right answer here, but it would certainly be much, much, much better for everyone involved (including the end users of your Debian package, people who install something that uses this library) if there were an active upstream. > Also the ABI is unlikely to change (since > no changes are being made). Yeah... see above about the upstream developers waking up one day and deciding to carry on :) Also, it is possible that some packager from antoher packaging system decides to go ahead and fork the project... But still, those are all hypotheticals. > I've previously suggested that maybe it would be better to set a > debian-specific version (0d?), to avoid the theoretical situation > that upstream one day ships a different ABI under the 1 so version. > > I would welcome peoples input here on what you think is best from > the debian perspective. Obviously we're going to be incompatible with > everyone else[1], unless you install/runtime-depend-on the -dev package > for the unversioned so symlink. Please speak now before this is > submitted for NEW. When you say "incompatible with everyone else", how do other packaging systems handle this? Has this library been packaged somewhere else? It might be a good idea to do the same thing as some other packaging system... but it may also turn out that all of the current ones have chosen (possibly different) suboptimal ways to handle this, so being incompatible with them may turn out to be the best option for Debian itself. As above, there is no single right answer here. > FWIW lzfse is needed to extract files compressed by Apple and shipped in macOS > containing embedded firmwares. See asahi-fwextract ITP: #1055206 > > Regards, > Andreas Henriksson > > > [1]: > https://salsa.debian.org/bananas-team/asahi-fwextract/-/blob/debian/unstable/debian/patches/0001-Use-versioned-library-name-for-liblzfse.patch G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1055198: ITP: lzfse -- LZFSE Compression library
Hi, * Andreas Henriksson [2023-11-04 18:05]: I've previously suggested that maybe it would be better to set a debian-specific version (0d?), to avoid the theoretical situation that upstream one day ships a different ABI under the 1 so version. Normally, I would agree, but in this particular case, Fedora already went ahead and used SOVERSION 1 [1], so that version is "burned" and we might just as well use it, too. [1] https://src.fedoraproject.org/rpms/lzfse/blob/rawhide/f/60.patch I would welcome peoples input here on what you think is best from the debian perspective. Obviously we're going to be incompatible with everyone else. I don't think that "incompatible" patch you linked creates much of an issue, because very few (if any) other library consumers will do this rather unusual dlopen() "soft linking" dance (normal linking with e.g. "gcc -llzfse" will automatically use the proper SONAME); besides, it is easy to patch in Debian packages and trivial to work around with "apt install liblzfse-dev" for everyone else. I do have one remark, though: the idea behind SONAME/SOVERSION is that you have a common name for all versions which are binary backwards compatible. Using the full version liblzfse.so.1.0 instead of libltfse.so.1 (i.e., the SONAME) in your patch defeats that purpose: it will only work with the exact version 1.0, but not any (hypothetical) future, backwards-compatible versions. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1055198: ITP: lzfse -- LZFSE Compression library
On Thu, Nov 02, 2023 at 01:04:03AM +0100, Tobias Heider wrote: > Package: wnpp > Severity: wishlist > Owner: Tobias Heider > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: lzfse > Version : 1.0 > Upstream Authors: > URL : https://github.com/lzfse/lzfse > * License : BSD-3-Clause > Description : LZFSE Compression library > > LZFSE is a Lempel-Ziv style data compression algorithm using Finite > State Entropy coding. It targets similar compression rates at higher > compression and decompression speed compared to deflate using zlib. > > I plan to maintain this as part of the bananas team. Calling all SO versioning experts! The upstream project does not have any shared object version set. A downstream patch was introduced to set one: https://salsa.debian.org/bananas-team/lzfse/-/blob/debian/unstable/debian/patches/0001-debian-set-library-SONAME.patch Upstream has seen no activity since 2017, so trying to interact is assumed to not generate much. Also the ABI is unlikely to change (since no changes are being made). I've previously suggested that maybe it would be better to set a debian-specific version (0d?), to avoid the theoretical situation that upstream one day ships a different ABI under the 1 so version. I would welcome peoples input here on what you think is best from the debian perspective. Obviously we're going to be incompatible with everyone else[1], unless you install/runtime-depend-on the -dev package for the unversioned so symlink. Please speak now before this is submitted for NEW. FWIW lzfse is needed to extract files compressed by Apple and shipped in macOS containing embedded firmwares. See asahi-fwextract ITP: #1055206 Regards, Andreas Henriksson [1]: https://salsa.debian.org/bananas-team/asahi-fwextract/-/blob/debian/unstable/debian/patches/0001-Use-versioned-library-name-for-liblzfse.patch
Bug#1055198: ITP: lzfse -- LZFSE Compression library
Package: wnpp Severity: wishlist Owner: Tobias Heider X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: lzfse Version : 1.0 Upstream Authors: URL : https://github.com/lzfse/lzfse * License : BSD-3-Clause Description : LZFSE Compression library LZFSE is a Lempel-Ziv style data compression algorithm using Finite State Entropy coding. It targets similar compression rates at higher compression and decompression speed compared to deflate using zlib. I plan to maintain this as part of the bananas team.
