libcdio-devel
[Top][All Lists]
Advanced

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

Re: [Libcdio-devel] should libcdio be declared 0.91 as is or with furthe


From: Rocky Bernstein
Subject: Re: [Libcdio-devel] should libcdio be declared 0.91 as is or with further changes ?
Date: Sun, 20 Oct 2013 18:43:42 -0400

There has been activity including what is described below that we should
probably put out another release possibly within a month or so.

Some of the activity over the last year has been centered around handling
large ISO9660's. But there have been other bug fixes and possibly upcoming
work to make this work smoother on Microsoft's Visual Studio.

Here are changes so far:

- Add udf_get_logical_volume_id to retreive a UDF Logical Volume
- Report Joliet level on iso-info
- More debug logging in reading lsn sectors
- Document how logging works in libcdio
- Fixes for reading large ISO 9660 images
- Enable Rock-Ridge handling in configuration by default
- Be able to read an audio CD with exactly 100 tracks
- Microsoft Windows fixes (mingw, cygwin)

In addition there may be an option added to iso-info to traverse the ISO
9660 for rock-ridge extensions. In theory this can be a very time-consuming
since potentially directory entries for every file may need to be checked.
So it won't be there by default. In practice, I suspect it won't be so bad.

Finally Natalia Portillo has been making some changes to update support for
Microsoft Visual Studio. See https://github.com/claunia/libcdio-osx (Here,
osx is a bit of a misnomer)


On Wed, Oct 16, 2013 at 9:09 PM, Leo Baschy <address@hidden> wrote:

> 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<https://savannah.gnu.org/bugs/?39354>- 
> fixed - Rock Ridge was disabled in default builds 0.83 - 0.90
>
> https://savannah.gnu.org/bugs/**?39373<https://savannah.gnu.org/bugs/?39373>- 
> fixed - .iso files >4G were not supported correctly ever
>
> https://savannah.gnu.org/bugs/**?40130<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<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]