Opened 11 years ago
Closed 4 years ago
#11448 closed Bug Report - General (Fixed)
mythwikiscripts and mythpython executables doesn't obey install prefix directory
Reported by: | Kenni Lund [kenni a kelu dot dk] | Owned by: | Bill Meek |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | MythTV - configure script | Version: | 0.26-fixes |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
When doing a clean install from source, the MythTV executables mythwikiscripts and mythpython gets installed in /usr/bin/ instead of in the install prefix directory specified by configure (/usr/local/bin/ by default):
[kenni@mediaserver diverse]$ ll /usr/local/bin/myth* -rwxr-xr-x 1 root root 631539 10 mar 11:33 /usr/local/bin/mythavtest -rwxr-xr-x 1 root root 21116978 10 mar 11:35 /usr/local/bin/mythbackend -rwxr-xr-x 1 root root 526068 10 mar 11:34 /usr/local/bin/mythccextractor -rwxr-xr-x 1 root root 6411421 10 mar 11:33 /usr/local/bin/mythcommflag -rwxr-xr-x 1 root root 412198 10 mar 11:37 /usr/local/bin/mythffmpeg -rwxr-xr-x 1 root root 4287370 10 mar 11:35 /usr/local/bin/mythfilldatabase -rwxr-xr-x 1 root root 40534686 10 mar 11:35 /usr/local/bin/mythfrontend -rwxr-xr-x 1 root root 334007 10 mar 11:33 /usr/local/bin/mythjobqueue -rwxr-xr-x 1 root root 2514979 10 mar 11:33 /usr/local/bin/mythlcdserver -rwxr-xr-x 1 root root 405015 10 mar 11:33 /usr/local/bin/mythlogserver -rwxr-xr-x 1 root root 479950 10 mar 11:34 /usr/local/bin/mythmediaserver -rwxr-xr-x 1 root root 958339 10 mar 11:36 /usr/local/bin/mythmetadatalookup -rwxr-xr-x 1 root root 470460 10 mar 11:34 /usr/local/bin/mythpreviewgen -rwxr-xr-x 1 root root 317002 10 mar 11:34 /usr/local/bin/mythreplex -rwxr-xr-x 1 root root 1151349 10 mar 11:34 /usr/local/bin/mythshutdown -rwxr-xr-x 1 root root 4523794 10 mar 11:36 /usr/local/bin/mythtranscode -rwxr-xr-x 1 root root 4046546 10 mar 11:36 /usr/local/bin/mythtv-setup -rwxr-xr-x 1 root root 2935424 10 mar 11:34 /usr/local/bin/mythutil -rwxr-xr-x 1 root root 1395457 10 mar 11:34 /usr/local/bin/mythwelcome [kenni@mediaserver diverse]$ ll /usr/bin/myth* -rwxr-xr-x 1 root root 1567 10 mar 11:22 /usr/bin/mythpython -rwxr-xr-x 1 root root 2517 10 mar 11:22 /usr/bin/mythwikiscripts
Change History (5)
comment:1 Changed 11 years ago by
Status: | new → infoneeded_new |
---|
comment:2 Changed 11 years ago by
Hmm, I really never gave it a thought that this behavior could be by design. When I compile a program, I always install it below /usr/local/ in order to keep it completely separated from programs installed with the package manager.
I assumed that this was a bug when I found the executables below /usr/bin, since I had configured the prefix to be /usr/local/ in the configure script (which also covers the Python bindings).
Perhaps it would be more user friendly to extend the output message from configure to include the Python bindings path(s)? At least that way the user gets a fair warning before installing.
# Bindings bindings_python yes [/usr/bin /usr/lib/python2.6/site-packages/]
Probably not the right syntax to use, as I believe the above syntax indicate source directories, but perhaps some other way of telling the user that the Python bindings ignores the install prefix?
comment:3 Changed 10 years ago by
Status: | infoneeded_new → new |
---|
comment:4 Changed 4 years ago by
Owner: | changed from beirdo to Bill Meek |
---|---|
Status: | new → assigned |
Bill, has this been fixed by recent changes?
comment:5 Changed 4 years ago by
Resolution: | → Fixed |
---|---|
Status: | assigned → closed |
I can't find a specific comment in the logs, but: d62595dd01cfb777acab9d01f3fb458eb34c063e from Sat Mar 10 2012 touches both scripts.
Scripts in the wrong location weren't removed. Anyone tripping over this ticked can use: ls -ld /usr/{,local/}bin/{mythpython,mythwikiscripts} to see what's installed. Use: type mythpython mythwikiscripts to verify that PATH is correctly setup to include /usr/local/bin.
Closing this one.
That's correct. If the install prefix is either /usr or /usr/local, the Python bindings and all associated executables ignore it, and leave the installation path up to whatever the Python installation tools are pre-configured to use. This is so they end up in the location Python expects to find them. Is there reason to change this behavior?