Re: [Libcdio-devel] ABI problem with: [PATCH v2] add multi extent ISO9660 file support to libcdio

[Pete Batard]

On 2018.06.27 16:03, Thomas Schmitt wrote:
> There is still the option of providing a new additional API.

Then I'm not going to be the one to submit that proposal, sorry.

> Currently i am not sure whether an API extension would be that much more
> development work

In that case, I'm going to respectfully ask someone else to do that 
work, because I have spent about as much time as I can allocate to 
adding multi-extent support to mainline libcdio.

If that's not suitable, then I'll just continue to use my modified 
version in Rufus, as I have been doing until now.

> On my olde Debian GNU/Linux there are installed
>
>    libcdio.0.83.a
>    libcdio.a
>    libcdio.so.13.0.0
>    libcdio.so.16.0.0

I thought that Linux had long solved the issue of ABI breakage through 
increasing major/minor as required. So I don't really see it as an 
issue. Breaking an ABI is not the end of the world, when we increase 
version numbers as required and the OS is properly designed to not load 
an ABI incompatible version of a library, which Debian should have been 
designed for long time ago.

> Largest optical medium is 128 GB. My personal main use case with ISO 9660
> is backup of data files. I play with large ISO images. So a 32 GiB data
> file is not totally unlikely.

Yes, and as I said, *when* we start to get reports that our extent 
support might no longer be adequate, *then* we'll deal with the issue, 
just like we did when we started to find multi-extent ISOs that libcdio 
could not handle. I may be an exception here, but as a downstream user 
of many libraries, I've never took much objection with having to update 
my code due to API breakage. On the contrary, I think regular API 
breakage *is* beneficial for end users, because it helps weed out 
applications that developers don't want to update, and that can 
ultimately become a liability due to their use of older libraries.

Regards,

/Pete