User's PATH after filesystem upgrade of 2013-06-03.

Question

Changing the directories /bin etc. to symbolic links to /usr/bin is transparent for most programs.  However, certain programs such as shotwell (see bug FS#35899 filed on this package) are sensitive to how they are invoked, as influenced by the PATH variable.  If /bin comes first in the PATH, then after the filesystem upgrade, shotwell is invoked as "/bin/shotwell" instead of "/usr/bin/shotwell".  As a result, shotwell looks in "/bin/../*" for stuff it needs, rather than in "/usr/bin/../*".  As a result, the unqualified invocation "shotwell" fails.  This appears to be due to shotwell's dependency on vala, so other vala-based programs may be affected.
A solution is to remove /bin, /sbin, and /usr/sbin from one's legacy PATH in .profile/.bashrc, etc.
Perhaps users should be warned about this in the upgrade instructions on the homepage.
Thanks to  Sid Karunaratne (sakaru) for isolating this problem.
Last edited by djraymondnm (2013-06-26 21:02:48)

Answer 1

Taking a pragmatic approach to this: as far as I know this is the only post about a bug like this. Now I know that doesn't mean it hasn't happened to other people, but unless it's a common problem I don't think we need to post a news bulletin or push post-upgrade messages into potentially breaking packages.
To be honest I'd consider this a bug in shotwell that should be fixed upstream, seems very odd that you can make the app but not run it until it's make install'd and executed from the installed location.
Thinking on more arch terms (as I understand them); This bug only occurs if you modified /etc/profile. Archlinux cannot start notifying users of breakages that may occur from all kinds of various configurations. I'm not saying that we should never notify users of potential breakages, but there should be limits and in my opinion this falls outside those limits.