Bug#856334: libdevice-cdio-perl: FTBFS when autobuilder has a CDROM drive

[Santiago Vila]

On Tue, 28 Feb 2017, gregor herrmann wrote:

> My CD-ROM "looks" like:
> 
> % ll /dev/cdrom
> lrwxrwxrwx 1 root root 3 Feb 16 19:06 /dev/cdrom -> sr0
> % ll /dev/sr0  
> brw-rw---- 1 root cdrom 11, 0 Feb 16 19:06 /dev/sr0

That's how my CD-ROM looks as well:

linode1:~# ll /dev/cdrom 
lrwxrwxrwx 1 root root 3 feb 27 19:42 /dev/cdrom -> sr0
linode1:~# ll /dev/sr0 
brw-rw---- 1 root cdrom 11, 0 feb 27 19:42 /dev/sr0

> I guess something™ is different with the CD-ROM in your build
> enviroment.

Yes, that's what it seems.

> Oh, and during autokpkgtest we always skip the two tests:
> 
> % cat debian/tests/pkg-perl/smoke-skip 
> # fail with QEMU's /dev/cdrom
> t/05.ops.t
> t/11.dev.t
> 
> 
> So it seems that those tests have proven to be problematic under
> other (virtual) versions of /dev/cdrom as well before, even if they
> work with real hardware.
> 
> If this is true we probably want to disable the tests completely
> during build as well ...

That's what I would do, yes.

Not only because some people have faulty cdroms, but also because we
want builds to be reproducible, so using /dev/cdrom when it exists
and not using it when it does not exist introduces a potentially
undesired variation in the way the package is built.

Ideally, special hardware should only be used at run time, not at
build time. Otherwise it becomes a requirement difficult to meet
for an autobuilder.

In either case, if you still want to debug this (just to satisfy
curiosity, and even if usage of /dev/cdrom is dropped), I can still
give you access to my machine (please contact me privately for
details).

Thanks.