For purposes of this email, please consider "/usr/lib64" to mean the right platform-specific thing. As the second step in my master plan to work on automated storage testing, I'm working on a patch to put anaconda under the python module path. Since anaconda builds shared objects, we need to put it under /usr/lib64. However, one side effect of making this change is that everything we had under /usr/lib/anaconda in the current system has moved to a similar place under /usr/lib64. In other words, /usr/lib/anaconda-runtime is now /usr/lib64/anaconda-runtime. command-stubs are now in /usr/lib64/anaconda. This is certainly consistent, but it also breaks a lot of places that assume these things are in /usr/lib/. If I'm going to break assumptions, I might as well only break them once and get all the paths right. So, here's how I propose we reorganize what anaconda drops into /usr: /usr/bin - Stays the same. /usr/lib64/anaconda - Remove all command-stubs we can, put the rest here. /usr/lib64/anaconda-runtime - Everything that's compiled stays in here. /usr/lib64/python?.?/site-packages/anaconda - All the typical python stuff we think of as "anaconda" goes here. /usr/sbin - Stays the same. /usr/share/anaconda - Everything that was already here, plus everything from /usr/lib64/anaconda-runtime that's not compiled. /usr/share/applications - Stays the same. /usr/share/doc - Stays the same. /usr/share/locale - Stays the same. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
