As the developer of libnfs I am asking for advice here. In order to implement "zero-copy" read support I had to break he API for read(), which realistically breaks the API for every single application. So I took the opportunity to fix other warts in the interface as well (like rpc_* functions should return a handle that could be cancelled)
This is a 100% API breaking change. So advice please on going forward. What does debian packaging and maintainer folks think? I am personally leaning towards leaving the current libnfs and API in a frozen maintenance state and publish the massive API changes in a libnfsv2 project? What should I do and how should I do it? The API changes are useful for going forward but they will break all backward compatibility. On Tue, 27 Jun 2023 at 22:15, Thomas Uhle <thomas.u...@mailbox.tu-dresden.de> wrote: > > Source: libnfs > Version: 4.0.0-1 > Severity: important > X-Debbugs-Cc: r...@debian.org, cnana...@debian.org > > Dear maintainers, > > libnfs has not seen any updates in Debian since almost four years. > Currently, there is version 5.0.2 upstream [1]. So can you please > update libnfs for Debian and also debian/watch to track the releases > at https://github.com/sahlberg/libnfs/releases/tags . > > Thank you in advance! > > Best regards, > > Thomas Uhle > > > [1] https://github.com/sahlberg/libnfs/releases/tag/libnfs-5.0.2 > > -- System Information: > Debian Release: 12.0 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') > Architecture: arm64 (aarch64) > Foreign Architectures: armhf > > Kernel: Linux 6.1.0-9-arm64 (SMP w/4 CPU threads; PREEMPT) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages libnfs13 depends on: > ii libc6 2.36-9 > > libnfs13 recommends no packages. > > libnfs13 suggests no packages. > > -- no debconf information >
