On Tue, May 20, 2008 at 01:41:20PM +0200, Josselin Mouette wrote: > Le lundi 19 mai 2008 à 19:22 +0100, Floris Bruynooghe a écrit : > > > The latter approach is less fragile overall, > > > > How is that? As far as I can see both python-central and > > python-support maintain directories for each python version and > > symlink the .py files to a shared location. Just on that basis I > > can't see why one is better then the other. Am I missing something > > here? > > 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.
Ack, that's a good reason to keep the tool-managed directory separate from /usr/lib/pythonX.Y/. > 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. What I do feel > strongly for, is putting them in a directory that remains separate > from /usr/lib/python2.X. I still do feel strongly about /var/lib, despite Pierre's good argumentation (I agree with him that a alternate shadow path directory for .pyc files would fix this). The problem is that not just the .pyc files end up on /var, but also the .py files (in symlink form). This makes it required to have /var on sys.path and that is what makes me feel really bad. I expect tools (not daemons and more exotic stuff that need runtime state) to work when /var is unmounted. Therefore I'd be much happier if python-support's managed directory was somewhere on /usr/. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]