Subject: Bug#3100: bug#3100

From: Bdale Garbee <[email-masked]>
Date: Sat, 1 Jun 1996 14:02:05 -0600

I believe that the right thing to do is either to have the 'rmt' executable
be provided as part of the tar package (not with cpio, as Brian Mays proposed
in his reply to this bug report, since tar is a base package and cpio is not),
or it should be kept as part of a separate package.  The more I think about it,
the more I favor the latter.

Brian and I have exchanged email about rmt being with tar instead of cpio,
and he asked whether 'mt' should then become part of the tar package as well.
It's not clear to me that this aggregation of mt with a particular archiver
makes any sense.  Opinions?

The more I think about it, the more I like the notion that rmt be part of a
package with or without mt that is suggested by tar and cpio.  It's not
essential for either, it's not necessary for rmt/mt to be present in a base
system, and yet it also makes no sense to force someone to install a cpio
package if all they want is the rmt executable to use with tar, dump, or
something else that knows how to use it.

Thoughts?

Bdale

---

From: Ian Jackson <[email-masked]>
Date: Tue, 4 Jun 96 03:18 BST

> the more I favor the latter.

I think this is unnecessarily granular.  We already have 400-odd
packages, can we please not create another tiny one for no
particularly good reason ?

> makes any sense.  Opinions?

mt and rmt are distributed by the GNU people with cpio.  cpio isn't
large, and ought to be installed on almost any system (it's sometimes
assumed to be present by things).

Is it really that awful to have to install cpio to get mt and rmt ??

Ian.

---

From: Lars Wirzenius <[email-masked]>
Date: Tue, 04 Jun 1996 14:23:16 +0300

> Is it really that awful to have to install cpio to get mt and rmt ??

# dpkg --listfiles cpio | xargs ls -ld | grep '^-' | awk '{ print $5 }' | /home/liw/bin/numsum
65506
# 

Not all that much extra, IMHO.  The above does not include mt at all.

# dpkg --listfiles cpio-mt | xargs ls -ld | grep '^-' | awk '{ print $5 }' | /home/liw/bin/numsum
25604
# 

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

---

From: Mike Coleman <[email-masked]>
Date: Tue, 4 Jun 96 04:45 CDT

Date: Tue, 4 Jun 96 03:18 BST
   From: Ian Jackson <[email-masked]>

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

(The package descriptions for both mt's don't really hint at the difference
between the two--I'm going to send a bug report on this...)

--Mike

---

From: Brian Mays <[email-masked]>
Date: Tue, 04 Jun 96 13:05:51 -0500

>>>>> "Mike" == Mike Coleman <[email-masked]> 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 <[email-masked]> 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 <[email-masked]>