Re: [lmi] Nomenclature for the new md5sum

[Greg Chicares]

On 2019-06-06 19:47, Vadim Zeitlin wrote:
>  Hello,
> 
>  This is a somewhat sophistical question, but is 3rd party md5sum program
> still 3rd party if it's compiled from our own sources?
> 
>  I'm asking this because of this comment in install_miscellanea.make:
> 
>       # The 'md5sum_msw' binary is redistributed to msw end users for
>       # authentication, so the 'fardel' target requires it. On other
>       # platforms, it cannot be executed directly, but it is needed for
>       # creating a cross 'fardel' and for running cross unit tests.
>       #
>       # It is placed in lmi's 'third_party/bin/' subdirectory--imperatively
>       # not in lmi's 'local/bin/' subdirectory, which is added to $PATH.
>       # For cygwin builds, the expressly downloaded 'md5sum.exe' is kept off
>       # $PATH to prevent it from shadowing cygwin's own version. However,
>       # for cross builds, it cannot shadow the native 'md5sum', yet some
>       # cross-built unit tests require an msw binary, so add its directory
>       # to $WINEPATH to make those tests work (incidentally, 'wine' doesn't
>       # find it if it's simply symlinked).
> 
>  Does it still make sense to install md5sum.exe we build ourselves into
> third_party/bin subdirectory? This seems misleading and I'd rather place it
> directly in $bindir, but this would go counter to the imperative above.
> OTOH I don't really understand the rationale for avoiding shadowing the
> Cygwin binary: why should it matter if both binaries work exactly the same?
> Granted, our new one will implement a strict subset of the official
> version, but as long as only this subset is used by lmi, it still shouldn't
> matter.
> 
>  And if it's really important to avoid confusion between the 2 versions,
> perhaps it would be better to rename our one to lmi_md5sum.exe or something
> else different from the official version?

I guess the safest answer is to call ours 'lmi_md5sum.exe' and place
it in 'third_party/bin/'. Then it's just a drop-in replacement for the
binary that we have always obtained from some external URL. That way,
nothing outside that very narrow use case can go wrong; and if anything
does go wrong in that case, it's trivial to revert to the old binary.

At some later date, we could reconsider whatever cygwin or wine issues
might arise, and perhaps decide to call it something else and install it
somewhere else. But that requires deeper thought to foresee any problems
that might arise. Time slots for deep thought are scarce.