[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] Split libiso9660 into its own project? (Was Re: [RFC

From: Pete Batard
Subject: 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)
Date: Mon, 9 Jul 2018 01:36:34 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]