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/lib<qual> : Alternate format libraries (optional)
Purpose
/usr/lib<qual> performs the same role as /usr/lib for an alternate
binary format, except that the symbolic links
/usr/lib<qual>/sendmail and /usr/lib<qual>/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]
