Re: [Q] Re: [PATCH] all my package fixes, mostly build-related

ms> Ah, OK, I see. So, I'm now even more confused: Are you saying ms> we should revert "the change that Stephen requested"? No, we should just make it right. See elsewhere in the thread for what I requested vs what I got, and the misconception I had that meant they were different. ms> You can't have both, i.e. ms> - prevent XEmacs from finding an old, rotten package root ms> sitting where you might install your XEmacs in the future symlinks can do that, too. That's what burned me, and got me to rm all the symlinks in my blddirs and substitute --package-path. (And nowadays I typically do rm -rf * in any blddir that hasn't been built in more than a week, which has the same effect.) ms> - get XEmacs to find a current package root sitting where you ms> might install your XEmacs in the future The common case with testers and at least this one developer is that XEmacs is in fact installed there, but you're running in place because it's a new build you want to test. In that case you want XEmacs to present you with the expected environment. Yes, I can achieve that effect now with symlinks, but I have to remember to do it, and nothing guarantees they'll be updated. I think XEmacs should default to doing the right thing by simplifying common cases. Requiring ad hoc changes in directory structure is not my idea of a righteous default. Stephen> According to the Info node quoted, package hierarchies Stephen> are expected under ${prefix}/lib/xemacs [but FHS says Stephen> they go under ${prefix}/share/xemacs]. ms> So what happens if you set --datadir instead of ms> --package-path? XEmacs happily fails to find the packages. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.