[Top][All Lists]

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

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

From: John Frankish
Subject: bug#21400: Location of "file" is hard coded
Date: Thu, 3 Sep 2015 20:06:17 +0400

> > > 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
> FHS agrees with me, AFAICT.
> > Are you saying that tinycorelinux puts optional (non-base) packages in

Yes :)

> 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
> even if everything really is built by the local admin.
> Where is the local admin supposed to put locally built stuff in
> if /usr/local is cluttered with optional distro packages?

If the app doesn't exist, the local admin compiles it to /usr/local and
submits it to the online repo it so everybody can use it.

> 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.

Tinycorelinux does offer a GNU file package, which is compiled to

Of course it's entirely up to you whether to ignore this or not, but as said
previously, it does not  seem logical to search $PATH for items like strip,
ranlib and nm, but not for file.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]