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

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

On Mon, Nov 11, 2002 at 03:49:29PM -0600, Manoj Srivastava wrote:
>  Raul> 	y=`md5sum < blah*.deb | awk '{print $1}'`
> 	Fails for md5sum /some/file >> hash-file-to-be-parsed-later

I'm not following you.  If you're not using md5sum on stdin,
and you don't pipe through awk at all, what's the problem?

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

Initially.  Priority should eventually be bumped up if the issue isn't
addressed and the new interface is still important.

>  Raul> Until all those bugs have been closed -- and until every package with
>  Raul> a md5sum dependency has had a chance to be tested -- we should forbid
>  Raul> deployment of the gnu version.
> 	How do we keep track of these bugs? 

Hmm... I guess we don't have a tool that says "given these bug
numbers, give me the status of each".  If we had such a tool
(seems easy enough to write), package maintainer for the
package with changing interface could run [maybe it once a week]
to track progress.

> 	This requires way more thought than this. Proper dependency
>  handling isa complicated; and a generic, scalable solution takes eons
>  to hammer out. 


> 	Ideally, the packages should provide a virtual package with an
>  interface version embedded in them (md-interface-1.1), and packages
>  depend on that interface; but even that fails to scale for packages
>  that may provide multiple interfaces, only some of which are
>  changing.

This also fails for packages which depend on something which hasn't been
virtualized yet.

More generally, unless we expose linking information at the package level
there will never be a completely automated handling of this kind of thing.
[That's what we expect package maintainers to sort out.]



Reply to: