Re: cpio

[mitchell@mdd.comm.mot.com (Bill Mitchell)]

Ian Murdock <imurdock@debian.org> said:

>    From: Jim Freeman <jfree@sovereign.sovereign.org>
>    Date: Mon, 4 Sep 1995 09:10:13 -0600 (MDT)
>    I'm a latecomer, but maintaining a package should help me learn
>    the packaging system.  Is anything expected besides getting the
>    current FSF source, compiling, running, and packaging it?
> I'm not exactly sure, but debian-devel can help.  Apparently, there is
> some problem with the mt program included with GNU cpio, and it should
> be replaced with another version of that program.  (Does that sound
> right, whoever reported this problem?)

For jim Freeman -- I haven't looked at the cpio package sources, but
I'd expect them to go together pretty easily.  Most GNU packages go
together pretty easily.  The biggest problem in taking over a package
is usually getting a copy of the un-debianized sources so the required diff
file can be built (sometimes the diff file which comes with the package
can be used for that, and sometimes not).  That's not a problem with GNU
packages, since the GNU sources are easily available.

For Ian and Jim -- The problem with the mt program included in the
cpio package, as I understand it, is that it doesn't support certain
scsi-tape-specific options which some people need.  An alternative
mt program is available in the mt-st package which apparently provides
the functionality provided by the mt program in the cpio package as
well as the needed scsi-specific functionality which that program lacks.

There's been talk about what to do about this but, as far as I know, no
decision.  It looks to me like at least the following alternatives are
available to be chosen between:

1.  Drop the mt-st package.  The people who need the functionality which
    it provides don't favor this.

2.  Keep things the way they are, with mt-st conflicting with cpio because
    both provide the mt program.  This leads to problems for users who
    need the cpio program from the cpio package and the mt program from
    the mt-st package.

3.  Unbundle the mt program from the cpio package into a package of its
    own which can conflict with the mt-st package.

4.  Replace the mt program in the cpio package with the mt program
    from the mt-st package, and retire the mt-st package.

5.  Remove the mt program from the cpio package and discard it.  Rely
    on the mt-st package for the mt program.

6.  Use Ian jackson's new update-alternatives script to coordinate
    installing the mt programs from the cpio package and the mt-st
    package as alternatives to one another.

I`m the maintainer of the mt-st package, but I'm not a stakeholder in
it.  I put it together in response to the complaints about the mt program
in the cpio package.  I'd be happy to go along with whatever plan is felt
to be workable. I'd be happy to turn the mt-st package over to someone else.
If jim Freeman is going to take up the cpio package, perhaps it might make
sense for him to take up the mt-st package as well.  (Jim?  What say?).