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

Re: making anaconda into a real python module



Hi,

On 02/10/2010 04:55 PM, Chris Lumens wrote:
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.


Sounds like a sane plan to me, I was really amazed recently when I
saw we put 64 bit .so files under /usr/lib/anaconda. So +1 !

Regards,

Hans


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