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 <tobias.heider@canonical.com> > > X-Debbugs-Cc: debian-devel@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 roam@ringlet.net roam@debian.org pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Attachment:
signature.asc
Description: PGP signature