[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cpio

Bill Mitchell writes ("Re: cpio"):
> [...]
> 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:
> [...]

I think we should do this in the meantime:

2b.  Leave mt-st in the distribution, but *not* declaring a conflict
     with cpio.  This will DTRT more of the time than having them

However, IMO the preferred solution is this:

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

or perhaps:

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

The decision between 4 and 5 is up to the cpio and and mt maintainers.

The next time something like this comes up I hope it will be possible

7.  Use (currently-unavailable) dpkg functionality to have the mt-st
    version of mt `override' that from the cpio package, pending
    implementation of option 4 or 5.

I have a draft design for the new functionality, but it's only in my
brain at the moment, and it will probably stay there until I implement
it (it's too simple to be worth writing a document about it).


Reply to: