Re: RFS: hashalot (updated)
On Fri, Jan 25, 2008 at 06:19:57AM +0530, Kapil Hari Paranjape wrote:
> Hello,
>
> Sorry about the delay in responding. Different time zones!
Hah, it's 4am, it's me who's hitting the bed now...
>
> On Thu, 24 Jan 2008, Adam Borowski wrote:
> > Actually, it seems that reverting to upstream autotooling doesn't break
> > anything (except obviously being unfriendly to those who want to update
> > autotoolage themselves). I would need to rename a file by hand in
> > debian/rules, that's all.
> >
> > Should I remove those parts from the diff?
>
> I think so. The package does not depend on anything substantial other
> than the C library and compiler. Updating the autotool-age should not
> be necessary.
Actually, it does check for all the headers, then... doesn't use that
information at all. configure.ac should be empty except for invoking
automake.
Even that old automake 1.7 upstream used knows where to install things good
enough. I thus reverted this part of the diff, reducing it by a factor of
20...
> I notice that you have shifted the man page from section 1 (used by
> upstream) to section 8. Since "hashalot" is not just a "command to be
> used by system administrators", I don't know why this has been done.
Matthias Urlichs did this because:
1. hashalot is good nearly solely for cryptsetup. A nicer interface for
using the hashes could be nice but SHA256, SHA384 and SHA512 are already
provided by "coreutils", so anything an user would use is RMD160. Which
was totally broken for anything but one-line strings until this upload
and no one complained.
2. binary output can be dangerous for an unwary user
> Rather than include the manpage you should patch the upstream
> manpage. (Upstream seems to have included the manpage written by
> Matthias Ulrich at some stage but the Debian packaging hasn't taken
> this into account).
Good point, fixed this.
> > In long-term, the package will most likely be absorbed into cryptsetup,
>
> Now that there is "luks", there is some doubt about this!
luks doesn't need an external helper for this task.
> Overall, it would be good if you simplified the Debian .diff.gz so
> that it is clear that it consists of (a) packaging (b) bug fixes to
> the upstream code. (Usually (b) is done by using "dpatch" or "quilt"
> but I won't insist on this).
Ok, I did this, then overwrote 0.3-5 on mentors. There's a watch file for
uscan now as well.
Bye for tonight!
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Reply to: