Hi,
Thomas Uhle <[email protected]> ezt írta (időpont: 2023. jún. 27., K, 16:00): > > Hello Ronnie, > > please find my 2 cents below ... > > > On Tue, 27 Jun 2023, ronnie sahlberg wrote: > > > 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? > > From a developer perspective (my view), this seems to be a quite > reasonable way to go. So it would be simply clear for an application > whether to link via '-lnfs' (still using the current API) or to link > via '-lnfs2' (using the new API from the future) similar to FUSE2/3 > for instance. And then also the path /usr/include/nfsc would need to > be changed to /usr/include/nfsc2 or anything alike, and libnfs.pc > would need to be renamed to libnfs2.pc to allow co-installability of > the different *-dev packages. > > 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. > > Personally, I would not start a new project if it would be possible to > implement a compatibility layer on top of the new API, maybe labelling > the older symbols as being deprecated. But if you need to keep the > same function names for the new API as well, then starting a new > project seems to be the best possible solution. I recommend keeping the original project & library name, bumping the SO version and providing a nice document for porting applications. Libnfs is used by a small number of (packaged) projects. The faster we phase out the previous API the better. Also the two projects would have to use different symbol names to avoid collisions. $ reverse-depends -b libnfs-dev Reverse-Build-Depends ===================== * far2l * gvfs * kodi * mpd * qemu * vlc > > > For now, this API breakage and zero-copy read is contained in the > > special libnfs-next-gen branch. > > But this has not yet been part of version 5.0.2, right? It does not seem so. I handed over the package maintenance ~1 year ago [1], but there has been no upload since then. To make it official I've uploaded 5.0.2 to experimental. Cheers, Balint [1] https://salsa.debian.org/debian/libnfs/-/merge_requests/1
