libcdio-devel
[Top][All Lists]
Advanced

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

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


From: Leo Baschy
Subject: [Libcdio-devel] should libcdio be declared 0.91 as is or with further changes ?
Date: Wed, 16 Oct 2013 18:09:32 -0700
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1

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), 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 source of some 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 I want 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, I suggest 39354 and 39373 are fixed in git and I think should be formalized in a numbered version tag so upcoming distros (RHEL 7.x, Ubuntu 14.04 LTS, MacPorts) can incorporate them.

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



reply via email to

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