Re: cdrtools alternatives
On Tuesday 15 August 2006 13:17, Nathanael Nerode wrote:
> Florian Weimer wrote:
> > * Nathanael Nerode:
> >> In reality, as "user A", I switched to using cdrdao for making serious
> >> audio CDs and CD-RWs, and for burning disks from .iso files: this uses
> >> Schilling's scsilib, but not the rest of cdrecord.
> >
> > What about mkisofs?
>
> Heh -- that's a point. Actually, I don't use it when creating audio CDs
> (for obvious reasons), and I don't usually create data CDs except by
> burning *other people's* .iso files, since I use DVDs instead lately.
> But I noticed that growisofs *does* use mkisofs as a backend.
>
> We definitely need a functional mkisofs in Debian.
>
> mkisofs is certainly part of cdrtools. But not of cdrecord.
>
> Nothing in mkisofs has weird conditions on the GPL, unlike other parts
> of cdrtools (libscg, cdrecord.c), so it should be straightforward to
> make a free fork. And it was originally written by Eric Youngdale.
>
> Likewise cdda2wav. It looks like the cdrecord package contains all the
> 'problem areas', and the other packages built from the cdrtools source
> package contain no problem areas.
>
> It's actually tempting to fork those two out as fully independent source
> packages. They have little to do, code-wise, with CD recording.
Right, forking up mkisofs only is one way to go, unless you find out that
mkisofs code is a little bit of mess and find it hard to maintain, but it is
not so bad anyway to stay there till a complete replacement matures enough to
take it over.
Fortunately there is a libburn (which contains libisofs) library to write
optical dics recorders and iso filesystem-creators apps on the top of that
like the recently packaged cdrskin. Unfortunately two libburn teams and
source trees exist [1] which makes their users to maintain an enhanced
snapshot for their own purposes, like cdrskin currently does. It currently
lacks tao, audio, multi features, and writes CD-R and CD-RW only, but the
upstream is active, very cooperative and tries to push improvements to the
pykix fork of libburn.
There is a nice attempt to post an empty hull of genisofs [2] (which is
intended to be based on libisofs) to the pykix fork ticket system. Currently
icculus's libburn is packaged in Debian, but it might be a good idea to
switch to pykix fork at some point.
While looking at #272644 it has been discovered that the open(2) manpage does
not describe completely how O_EXCL option acts on a block device. I.e. what
happens if an app using open(2) with O_EXCL | O_CREAT is run on the top of an
old kernel which does not contains that O_EXCL functionaly. We found that
post to lkml and I think that it would be nice to extend open(2) manpage with
that important information. I will file a wishlist bug against manpage-dev at
some point later.
[1] the original effort http://icculus.org/burn/ (already packaged in Debian)
and a recent fork at http://libburn.pykix.org
[2] http://libburn.pykix.org/ticket/24
http://libburn.pykix.org/wiki/GenIsoFs
[3] http://lkml.org/lkml/2006/2/5/137
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Reply to: