[Libcdio-devel] should libcdio be declared 0.91 as is or with further changes ?

[Leo Baschy]

Summary:

Linux distributions should have good versions of libcdio. Ability to 
read Linux distro .iso files via iso-info and iso-read probably should 
be restored / maintained.

Therefore, current git HEAD containing fixes for bugs 39354 and 39373 
probably should be formalized in a numbered version tag 0.91 so upcoming 
distros can incorporate them.

A couple more issues are less pressing, and may deserve discussion.

Background:

We had started using libcdio’s iso-read and iso-info in Linux (on Linux 
hosts) to process Linux distro .iso files. At first on RHEL (Red Hat 
Enterprise Linux) 6.x, which has been and still is at libcdio version 
0.81. That got us far, with our (free and open sourced) automation 
application (NrvrCommander), which sets up virtual machines (controls 
them, etc.).

First uses were Linux installations (in VMs) hosted on Linux, for QA and 
development. In time we expanded from making RHEL on RHEL to making RHEL 
(and derivatives) and Ubuntu on RHEL (and derivatives such as CentOS, 
Scientific Linux), on Ubuntu, and on Mac OS X. Other OSes in the works.

Reading .iso files is an essential part that however is NOT on the mind 
of automation users - they merely want the resulting VMs.

We found defects that affect many users:

The versions of libcdio we found in Ubuntu 12.04 LTS (0.83 in a package 
called libcdio-utils) and 13.04 and Mac (0.90 in MacPorts) were 
defective (non-functional) for the purpose of reading Linux distro .iso 
files. Defective as in: Don't work for reading popular contemporary 
Linux distro .iso, and cannot be worked around, not with any optional 
parameter or setting. Details of defects below. Even in 0.81 we found a 
defect (could not read .iso files >4G).

The good news:

I was able (with guidance from Rocky “where to look”) to identify the 
sources of a couple defects, file bugs, help one fix, and implement 
another fix, with reproducible test scripts. Details below.

The scary news:

RHEL will go 7.0 soon. Beta probably late 2013. RHEL for all of 6.x 
stayed with libcdio 0.81. If RHEL goes 7.0 with libcdio anywhere from 
0.83 to 0.90 that would actually be a step back. (Assuming they’d build 
it as-is from that version git tag.) That could stick for years.

Why there should be a 0.91 version declared (with today’s git HEAD):

While someone who is motivated and skilled can spend time on building 
libcdio from git HEAD, that is not a preferred mode for most users.

Linux distributions should have good versions of libcdio. Ability to 
read Linux distro .iso files via iso-info and iso-read probably should 
be restored / maintained.

Essential fixes are in git already. Those should go into a version 0.91 
for sure, so distros have a version they can pick up.

Additional changes may be worth discussing, but should not be in the way 
of getting a version 0.91 declared, given the somewhat unsettling 
prospect of RHEL 7.x for years staying with a current version, again.

The bugs:

https://savannah.gnu.org/bugs/?39354 - fixed - Rock Ridge was disabled 
in default builds 0.83 - 0.90

https://savannah.gnu.org/bugs/?39373 - fixed - .iso files >4G were not 
supported correctly ever

https://savannah.gnu.org/bugs/?40130 - maybe should be discussed - need 
to use iso-info --no-joliet -f (or -l) to get correct listings of 
popular Linux distro .iso files

https://savannah.gnu.org/bugs/?40138 - maybe should be discussed - need 
to use iso-info --no-joliet -f (or -l) to get correct listings of 
certain test cases

To be clear, bugs 39354 and 39373 are fixed in git and this should be 
formalized in a numbered version tag so upcoming distros (RHEL 7.x, 
Ubuntu 14.04 LTS, MacPorts) can incorporate this.

A discussion of 40130 and 40138 should not prevent timely release (with 
a version number tag) of 39354 and 39373.