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