Bug#3100: bug#3100

[Brian Mays <bem5r@neutron.mane.virginia.edu>]

>>>>> "Mike" == Mike Coleman <coleman@chez-gnu.cstp.umkc.edu> writes:


    Mike> No, except that there are two conflicting mt's, and from
    Mike> perusing /usr/src/linux/drivers/scsi/README.st, it looks to
    Mike> me like the one that doesn't come with cpio (i.e., mt-st) is
    Mike> the better one to use.  If mt gets bundled with cpio, users
    Mike> will have to choose between cpio and better mt.

Okay.  Here's the deal with mt.  The only advantage that mt-st has had
over GNU mt is that mt-st has been hacked to support SCSI tape drives
(which is why the README packaged with the SCSI tape drivers
recommends it).  This is no longer true, since I have added SCSI
support to Debian's version of GNU mt.

Since my new version of GNU mt was untried, I did not include it in
the cpio package (and instead placed it in its own small package
cpio-mt) for the reason cited above, that is I did not want to force
users into a decision between cpio and a version of mt that is known
to support SCSI drives.  In the time since I released cpio-mt for
testing, I have received one bug report, which I have fixed, and one
message indicating that the SCSI features of GNU mt work.  I can't
test the SCSI features of mt myself because I don't have a SCSI drive.

Now that it supports all of the SCSI features, GNU mt is the superior
version of mt.  The other version, mt-st, is lacking some operations
supported by GNU mt, and it cannot access remote tape drives via rmt.
Furthermore, I've found that mt-st does not support floppy-controlled
(FTAPE) tape drives, which I use.

>>>>> "Lars" == Lars Wirzenius <liw@iki.fi> writes:

    Lars> BTW, both dump and cpio-mt have rmt, dump in /sbin/rmt,
    Lars> cpio-mt in /usr/sbin/rmt.  Is this on purpose?

I was not aware of this.  I'll download and look at dump soon.  In
cpio-mt, I placed rmt in /usr/sbin because I did not think that it
qualified to be placed in /sbin, especially since cpio and mt, which
use rmt, are located in /usr/bin.  Can anyone argue for placing rmt in
/sbin?  I also symbolically linked rmt into /etc since this is where
tar, cpio, and mt will look for it.

--
Brian <brian@debian.org>