Josselin Mouette [EMAIL PROTECTED] writes:
The python-central approach puts in the same directories files
managed by dpkg and files managed by python-central, which means
they cannot be sorted out easily, and if you run in a bug like
#409390 or #480741, you’re hosed.
If anything ever gets wrong with python-support, all you need to do
is to run update-python-modules -f and the /var/lib/python-support
hierarchy will be entirely regenerated.
I find this a convincing argument for separating the source and
compiled versions (and thank you, I hadn't thought of this).
I don't see that it leads to storing the compiled programs to live
under /var/, rather than /usr/ which to my mind is more appropriate
for compiled versions of programs installed by the package manager,
which don't change except through explicit sysadmin action to change
them.
As for the FHS argument, I don’t feel strongly for putting these
files in /var/lib, it just seemed like the most obvious location as
this is data that can be regenerated at any time. It can be changed
very easily if there is consensus that another place is better.
FHS 2.3 §4 allows for:
/usr/libqual : Alternate format libraries (optional)
Purpose
/usr/libqual performs the same role as /usr/lib for an alternate
binary format, except that the symbolic links
/usr/libqual/sendmail and /usr/libqual/X11 are not required.
[26]
Python source code versus compiled Python bytecode certainly
qualifies as an alternative binary format, so this seems the most
applicable section of the FHS.
Would '/usr/libcompiled/' or '/usr/libbytecode/' be an appropriate
hierarchy to place locally-compiled bytecode for package-installed
software?
What I do feel strongly for, is putting them in a directory that
remains separate from /usr/lib/python2.X.
Thanks for your convincing argument, I'm now in support of this much.
--
\ When I was little, my grandfather used to make me stand in a |
`\ closet for five minutes without moving. He said it was elevator |
_o__) practice. -- Steven Wright |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]