GNOME Bugzilla – Bug 721167
install-check is silly with DESTDIR installs
Last modified: 2015-11-10 09:58:56 UTC
We should drop install-check. It's totally pointless when we're installing to a DESTDIR and copying the files into place. It's also potentially problematic when mixed with .pyc files in the case that we don't do a DESTDIR install (for some reason). The .pyc file can be updated (due to the fact that it contains a timestamp) and will therefore be installed, but the original .py file wouldn't be because it's the same. This means that the timestamp in the .pyc file would mismatch the installed .py file (which would either be equal to the timestamp that it was checked out of git, or that it was generated, if that is the case).
*** Bug 665085 has been marked as a duplicate of this bug. ***
Created attachment 315163 [details] [review] install-check: Drop as no longer useful and potentially dangerous `install-check` is totally pointless when installing to a DESTDIR and copying the files into place, which nowadays is JHBuild's normal method of operation. It's also potentially problematic when mixed with .pyc files in the case that we don't do a DESTDIR install (for some reason). The .pyc file can be updated (due to the fact that it contains a timestamp) and will therefore be installed, but the original .py file wouldn't be because it's the same. This means that the timestamp in the .pyc file would mismatch the installed .py file (which would either be equal to the timestamp that it was checked out of git, or that it was generated, if that is the case).
Review of attachment 315163 [details] [review]: Right.
The following fix has been pushed: 18aaf92 install-check: Drop as no longer useful and potentially dangerous
Created attachment 315179 [details] [review] install-check: Drop as no longer useful and potentially dangerous `install-check` is totally pointless when installing to a DESTDIR and copying the files into place, which nowadays is JHBuild's normal method of operation. It's also potentially problematic when mixed with .pyc files in the case that we don't do a DESTDIR install (for some reason). The .pyc file can be updated (due to the fact that it contains a timestamp) and will therefore be installed, but the original .py file wouldn't be because it's the same. This means that the timestamp in the .pyc file would mismatch the installed .py file (which would either be equal to the timestamp that it was checked out of git, or that it was generated, if that is the case).