On Sun, 12 Aug 2012 22:57:41 +0100, "Adam D. Barratt" writes:
>Ping?

sorry for the late response: after digging through this a few more times
i've got an explanation for the debdiff output.

in 0.2.0-1 there were some local changes to vmm, precisely the ones
that debdiff reports now (in reverse): ie. the change from 
Number::Bytes::Format to Number::Format and the VMware::VIRuntime loading
in eval.

for 0.2.0-2 i renamed vmm to vwm, and adjusted the inline pod sections
to reflect that name change. nothing else was modified.

the problem is that the debian diff doesn't represent file deletions,
and that i rather should have left the vmm filename intact and just 
installed it with its new name via debian/rules (hindsight and all that).

net effect: a newly unpacked 0.2.0-2 includes the correct vwm file,
but also a superfluous and unused vmm file from the orig tarball, 
which of course reflects only the state before the -1 changes were made.

what's the verdict? upload a new version -3 that avoids the filename changes 
and concomitant spurious difference reports, or accept the current status
with vmm(from -1) identical modulo doc changes to vwm(from -2) and ignore
the unnecessary vmm(from orig tarball)?

regards
az


-- 
Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/
When you understand UNIX, you will understand the world.
When you understand NT....you will understand NT -- R. Thieme

Attachment: signature.asc
Description: Digital Signature

Reply via email to