Re: Bug#164889: md5sum <FILE produces spurious ` -' in output

[Raul Miller <moth@debian.org>]

On Mon, Nov 11, 2002 at 03:31:51PM +1000, Anthony Towns wrote:
> debootstrap broke. Things of the form:
> 	x=`cat foo.changes | grep blah.*deb | cut -d\  -f2`
> 	y=`md5sum < blah*.deb`
> 	if [ "$x" != "$y" ]; then

Hmm...

There are essentially two approaches to this class of problem.

[1] require that md5sum not break this kind of code.

[2] require that this code be modified to work with the "new" md5sum.

If we're going to go with [2], we can require a change of the form:

	y=`md5sum < blah*.deb | awk '{print $1}'`

Or, we can require a special option, so we get something like

	y=`md5sum --clean < blah*.deb`

I guess the technical issue here is the cost of the requisite fork()
and system behavior under degraded circumstances.  Since debootstrap
hasn't really been designed for degraded running, I don't think this
issue is significant.

Here's my opinion:

Since making this kind of change doesn't break use of the existing
md5sum, I think we should recommend that all apps using md5sum test
using the gnu variant and be modified so they work with either version.
In particular, we should allow bugs to be filed against packages which
don't support the gnu version.

Until all those bugs have been closed -- and until every package with
a md5sum dependency has had a chance to be tested -- we should forbid
deployment of the gnu version.

Also, taking a step back:

Once we're done with this specific issue, maybe we should think about
making this kind of phase-in process an option for package developers
to introduce on their own.  In other words, allow people to say:

a I'm going to change XXX in a way that breaks the existing interface.

b You have a package with a dependency on my packages which contains XXX.

c Here's one way to write code that will work with either interface.

d Here's where to get an instance of the new interface for you to test
  against.

e [stuff about bug filing/closing and the eventual release of the new
  interface]

Comments?  Opinions?

One thing that bothers me about these kind of migrations is that older
packages aren't going to know about interface changes introduced in
newer packages.  This almost requires a [potentially large and ugly]
versioned "Conflicts:" in the package which supplies the new interface.

Thanks,

-- 
Raul