[bug#28398] Xfburn

[Thomas Schmitt]

Hi,

Ludovic Courtès wrote:
> http://cvs.savannah.gnu.org/viewvc/*checkout*/womb/gnumaint/pkgblurbs.txt
> However in this case our Xorriso description seems to differ.
> Are you OK with the one in pkgblurbs.txt above?

I'm not sure whether the last sentence could be misleading:
  "xorriso can then be used to copy files directly into or out of ISO files."

"ISO files" should be "ISO filesystems", in any case.

"copy files directly into" might suggest usual read-write capabilities.
But as mentioned by "session-wise manipulation", the write capability is
not the usual one.

It works like this:
- The directory tree and metadata of an ISO filesystem get loaded into
  the object model of libisofs,
- libisofs applies manipulations to this model,
- finally a new directory tree based on the model gets written to the
  medium, together with any new data file content.
Old directory trees and the data file content of outdated files stays
unchanged. Only the superblock of the filesystem will get overwritten,
if the medium is overwritable. On non-overwritable media, the Linux kernel
will look for a superblock in the first track of the last recorded session.

To get an idea how sessions are arranged on a BD-R medium, see
  https://screenshots.debian.net/package/xorriso
On GNU/Linux, mount option -o sbsector= can mount any of the 10 sessions
to show the ~4 GB backup state of the day when the session was made.
Although the add-on sessions only introduced content of changed data files,
they still impose substantial overhead by each having a tree of 60,000+
file names. (But hey, it's already worth 40 GB of backup and will take
about 200 more daily sessions.)


> As package maintainers our choice is to *not* use bundled software in
> such cases, though.  Is it the only difference between the two xorrisos?

Feature- and bug-wise: yes.
There is the built-in copy of libjte in GNU xorriso, which one would have
to offer libisoburn at configure-, build-, and run-time, in order to get
the same capability of creating Debian .jigdo and .template files.
See also  https://www.debian.org/CD/jigdo-cd/

Name-wise there are problems with some from-source distros which have
a 1:1 relationship between source package and installed set of binaries.
They are unable to offer a package named "xorriso" but only its upstream
package "libisoburn".
(I could have changed this by splitting up the three upstream tarballs
 into six, some years ago. But i did not like the idea much and my then
 Debian Developer hated it thoroughly. Meanwhile it would cause work in
 too many distros.)
Afaik, the FreeBSD port of libisoburn is named "xorriso".
Archlinux has a "Provides:" header where its "libisoburn" package
advertises "xorriso, xorriso-tcltk".

Any difference results from automatic creation of GNU xorriso from the
library sources by
  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/xorriso/make_xorriso_standalone.sh
It makes changes about:
- Build system files: bootstrap, configure.ac, Makefile.am, version.h.in
- Documentation files: CONTRIBUTORS, README, COPYRIGHT, COPYING, AUTHORS
- Program id message and license statement control macro in xorriso/xorriso.h


Have a nice day :)

Thomas