Re: [Libcdio-devel] Split libiso9660 into its own project? (Was Re: [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB)

[Pete Batard]

On 2018.07.08 23:52, Rocky Bernstein wrote:
> But we're talking about  a library

No. I'm not.

In the point I was making earlier, I was talking only about downstream 
applications that might use our library, but not the library itself, as 
I consider libcdio to be actively maintained, and therefore not suffer 
from the point Thomas was trying to make (which I assert was also 
entirely about downstream apps, and not libcdio itself).

> The reality is that the need VCD, CDDA, and CD reading in general and MMC
> control has diminished. So this project is a little different than say the
> next version of Python where there still is a lot of popularity.

Exactly why I see it more than okay to break the ABI at some stage, and 
why I don't foresee a lot of people using more than 8 extent, as, 
realistically speaking, libcdio is not popular enough to see a large 
number of people being negatively hurt by a hardcoded limit (which, 
again, we can work around, without having to use Thomas' full proposal, 
if we really feel it's going to materialize as an insurmountable issue 
for our users). If it helps, just consider that the hardcoded limit is a 
non issue (because Thomas has done separate work to make it not so on 
top of my earlier proposal), and just consider that the point of 
contention is about an ABI breakage (and _only_ an ABI breakage).

> There is a
> lot less incentive for developers to keep such code up to date.

But if we find an issue in any of these less maintained parts, we will 
fix them. This is vastly different from apps where this doesn't happen 
at all, which is what I was talking about. I am pretty sure Thomas' 
point was about how an ABI breakage may impact downstream apps, that are 
still being used, but that have no active maintainer.

Well, if libcdio was a downstream application from another library 
(which I don't believe it is, but maybe there are parts I am not aware 
of where we are) and that upstream library broke its ABI, then because 
we have active developers, I have little doubt that we would update 
libcdio to sort any ABI issue. This disqualifies libcdio as "poorly 
maintained" software in my book.

> To move to libcdi 1.0 and 2.0 it was a bit of a hassle to update the
> libcdio Perl and Python binding.

Yes. But you will still need to go through that, regardless of the 
option we choose, if you want to provide multiextent support, which, for 
end-users sake, I will argue "we" should provide for Perl & Python.

Extent support is an expected feature of an ISO-9660 library, so I don't 
think we should consider that it will ever be okay for Perl or Python 
users not to have it, when we have it in the base lib, when we know that 
they may try to process something like blackarch-linux and find that it 
doesn't work.

> And when you think about it. I doubt
> there are any VCD's in existence than need or use multiple extents.

Then, just recompile for the new library, with no change to the source. 
Remember our worst case scenario here is an ABI change. Not an API 
change. Regardless of what we pick, the old API will continue to work 
for the foreseeable future.

> So looking at it from a VCD developer's standpoint: why should I have to
> rewrite code as a result decisions made about large ISO-9660 files that
> have no bearing on VCDs?

You don't, since the API will not change. You will just need to 
recompile for the new ABI (if there's even something that needs to be 
done for that), but no code changes are going to be required.

I would expect that this gets sorted automatically, even when using a 
shared library if we update our major/minor appropriately so that the 
system can find its expected bearings.

Regards,

/Pete