[bug#28398] Xfburn

[Thomas Schmitt]

Hi,

ng0 wrote:
> I've applied your suggestions
> and the ones Christopher had a while back in this new version
> of the patches.

The inappropriate word "mastering" is still in one of the two description
texts in the libburn patch

> +    (synopsis "Library for reading and writing optical discs")
> +    (description
> +     "Libburn is a library for reading, mastering and writing optical discs.


(It is also still in the description of the current Debian package. But
 that's only due to the long release cycle. The next Debian package will
 state what is committed by
   
https://anonscm.debian.org/viewvc/pkg-libburnia/trunk/libburn/debian/control?r1=428&r2=430
)

------------------------------------------------------------------------

With Xfburn, consider to mention BD (Blu-ray) media additionally to CD and
DVD media. 

> +    (synopsis "GTK+ based CD and DVD burning application")
> +    (description
> +     "Xfburn is a simple CD/DVD burning tool based on libburnia
> +libraries.  It can blank CD/DVD(-RW)s, burn and create iso images,
> +audio CDs, as well as burn personal compositions of data to either
> +CD or DVD.")

I can confirm that "xfburn version 0.5.2 for Xfce 4.10" recognizes and
burns single layer BD-RE and BD-R media. Users of libburn report success
with multi-layer BD-RE and BD-R media.

------------------------------------------------------------------------

Did we already talk about these lines in the libburn patch ?

> +     `(#:configure-flags (list "--enable-libcdio")))
> +    (inputs
> +     `(("libcdio" ,libcdio)))

If they shall by default let libburn use the SCSI transport mechanism of
libcdio, then better don't do this.

Without wanting to badmouth libcdio, it turned out that its SCSI/MMC layer
is needy of modernization and that it does not provide usable SCSI transport
on operating systems which libburn cannot handle by its own system adapters.
libburn has SCSI-capable adapters for Linux The Kernel, FreeBSD, Solaris,
NetBSD, OpenBSD.

In Hurd/Mach The Kernel we have no SCSI transport facility from userland to
optical drives, i fear. There, libburn can only operate on data files and
read-write block devices. Useful mainly as foundation for xorriso to make
ISO 9660 filesystem images.

The shortcommings of libcdio towards libburn's sg-linux.c adapter are mainly
with receiving SCSI error conditions (aka Sense Data) from the drive and
forwarding them to libburn.

So my advise is not to configure libburn with --enable-libcdio and not to
declare libcdio a dependency of libburn.

------------------------------------------------------------------------

I also looked at the libisofs related patch:

> +    (inputs
> +     `(("zlib" ,zlib)))

If ./configure sees libacl and libattr on GNU/Linux, then libisofs will link
to it and enable recording of ACL and extended file attributes.

Looking for "acl" in Guix, i found
  
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/acl.scm?id=v0.13.0-5000-gd2bdee8a6#n33
which looks like what Debian packages as "libacl1" and is used by Debian's
libisofs package.

So consider to add for libisofs
      ("acl" ,acl)

----------------------------------------------------------------------------

GNU xorriso versus libisoburn's xorriso:

The only known application of libisofs' ACL capabilities is xorriso. It can
record ACLs as part of backups and restore them back to disk. Operating
systems are supposed to ignore the ACL info when mounting and reading
libisofs made filesystems.

Guix currently packages GNU xorriso, which brings own source copies of
libburn, libisofs, libisoburn, and libjte.

When libburn and libisofs are established as Guix packages and the decision
is made that Debian's Jigdo ISO download mechanism is not desired, one should
consider to package libisoburn and to install its dynamically linked xorriso
binary.

The source code and functionality of both xorrisos is the same, except that
Guix offers no libjte for Debian's Jigdo format. Both are maintained by me.
libisoburn is GPLv2+, but by using libreadline it will become GPLv3+.
GNU xorriso is always GPLv3+.

Reason for the existence of GNU xorriso is mainly that it can be compiled
and installed by a normal user without interfering with system-wide installed
libburn and libisofs. This provides freedom from distro decisions and delays.

Guix's xorriso package has at
  
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/cdrom.scm?id=v0.13.0-2323-g35131babc#n148
>     (inputs
>      `(("acl" ,acl)
>        ("readline" ,readline)
>        ("bzip2" ,bzip2)
>        ("zlib" ,zlib)
>        ("libcdio" ,libcdio)))

The use of "bzip2" seems wrong. libjte optionally uses libbz2 which i don't
find in Guix. "bzip2" does not promise the library but rather the standalone
binary.

The use of "libcdio" would have the disadvantage described above. But
it seems that it is not enabled at configure time of GNU xorriso.
So one should remove it from the xorriso input list, too. 

------------------------------------------------------------------------

Whew. I did not plan to write such a long mail.


Have a nice day :)

Thomas