bug#21400: Location of "file" is hard coded

[Peter Rosin]

On 2015-09-03 10:25, John Frankish wrote:
>> I had a quick look, and AFAICT, all uses of hardcoded /usr/bin/file are in
> system-specific code paths.
>> So, you must have the file utility in an odd location for your type of
> system
>> (and /usr/local/bin seems a bit odd for a basic utility such as file).
> 
> This distro (tinycorelinux) works on the basis that anything not in the base
> release should be compiled to /usr/local, which I believe was the original
> idea of /usr/local.
> 
> As can be seen from above, the configure script finds strip, ranlib and nm
> in /usr/local so it would be kind of logical that it could find file in the
> same place, no?

I always thought that /usr/local was for stuff built locally by the local
admin. FHS agrees with me, AFAICT.

Are you saying that tinycorelinux puts optional (non-base) packages in
/usr/local? Seems like a very bad call to me, diverging from every other
distro and unix history is painful, to put it plainly. Not even Gentoo
goes as far as putting stuff in /usr/local, even if everything really is
built by the local admin. Where is the local admin supposed to put
locally built stuff in tinycorelinux, if /usr/local is cluttered with
optional distro packages?

And, I refuse to think that tinycorelinux does not, at least optionally,
offer a GNU file package, so I would suggest that you install that package
and move on (it's not like Libtool depends on any state-of-the-art
option that is only available since file version x.y). If 'file' ends up
under /usr/local when you do that, switch to a sane distro instead.

Besides, as always, whatever Libtool upstream does, it will take a long
time for any change to reach all the packages that you likely want to
build ASAP. So, anything you do to make up for this file problem will
probably not go away anytime soon.

Also see: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17840

Cheers,
Peter