Bug#1032941: Additional use of Rock Ridge symbolic links in bookwork ISO images

[Pete Batard]

Package: debian-cd
Version: debian-testing-amd64-DVD.iso (2023.03.08)

This is a requested follow up to #1031696
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031696).

Besides essential installation packages using symlinks, the upcoming
bookworm also uses symlinks for non essential files, such as documentation.

Personally, I don't see this use as a major issue, since it doesn't
prevent installation when using file system transposition to create the
UEFI installation media (for clarification about what file system
transposition is, see the second paragraph of #1031696), but it would
probably be nice to investigate whether a different approach could be
used for these links.

Below are the links that detected on recent bookworm DVD ISOs, as
reported by Rufus during file extraction to a FAT32 file system:

Extracting: /debian (0 bytes)
Ignoring Rock Ridge symbolic link to '.'
Extracting: /dists/testing (0 bytes)
Ignoring Rock Ridge symbolic link to 'bookworm'
Extracting: /doc/FAQ/html/basic-defs.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'basic-defs.en.html'
Extracting: /doc/FAQ/html/choosing.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'choosing.en.html'
Extracting: /doc/FAQ/html/compatibility.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'compatibility.en.html'
Extracting: /doc/FAQ/html/contributing.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'contributing.en.html'
Extracting: /doc/FAQ/html/customizing.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'customizing.en.html'
Extracting: /doc/FAQ/html/faqinfo.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'faqinfo.en.html'
Extracting: /doc/FAQ/html/ftparchives.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'ftparchives.en.html'
Extracting: /doc/FAQ/html/getting-debian.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'getting-debian.en.html'
Extracting: /doc/FAQ/html/index.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'index.en.html'
Extracting: /doc/FAQ/html/kernel.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'kernel.en.html'
Extracting: /doc/FAQ/html/nextrelease.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'nextrelease.en.html'
Extracting: /doc/FAQ/html/pkgtools.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'pkgtools.en.html'
Extracting: /doc/FAQ/html/pkg-basics.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'pkg-basics.en.html'
Extracting: /doc/FAQ/html/redistributing.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'redistributing.en.html'
Extracting: /doc/FAQ/html/software.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'software.en.html'
Extracting: /doc/FAQ/html/support.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'support.en.html'
Extracting: /doc/FAQ/html/uptodate.html (0 bytes)
Ignoring Rock Ridge symbolic link to 'uptodate.en.html'

Regards,

/Pete

[Thomas Schmitt]

Hi,

the use of xorrisofs/genisoimage option -f would convert those links
into shared content data files, too.


Side note:

Differing from my statement in bug #1031696, the current xorriso version
does not complain about dangling symbolic links when -f is given. It
silently includes them as symbolic links in the ISO.
I will change the behavior so that a SORRY message is emitted in this
case. With default settings of xorriso this will cause a non-zero exit
value of xorriso. But processing will go on as with the current version.

genisoimage -f emits a warning and does not include the dangling link in
the result. I.e. the file is missing in the ISO.


Have a nice day :)

Thomas