[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

making anaconda into a real python module

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

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

/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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]