On Wed, Sep 11, 2002 at 04:57:51PM +0200, Tollef Fog Heen wrote: > * (Donovan Baarda) > > | On Sun, Sep 08, 2002 at 02:49:24PM +0200, Tollef Fog Heen wrote: > > | > Those scripts get a parameter saying which emacsen which is being > | > installed, so they can decide whether they work with that version or > | > not. > | > | If they don't work with that version, then what? Are dependancies used to > | ensure packages are not installed without a compatible version of emacs? > > yes (that at least one version which with the package works is > installed). > > | Can emacs support parallel installation of multiple versions of emacs? Where > | are the compiled files kept for each installed version? > > in a version-specific load-dir. > > | By convention Python likes to keep it's *.pyc files in the same directory as > | the *.py files. This means you either support a single version of python at > | a time (ie, the default "python"), or you provide different directories for > | each supported version of python (ie, /usr/lib/python2.1, > | /usr/lib/python2.2, etc). How does emacs handle this? > > if you want to do that, the python-install script would copy the .py > files and compile them and not remove them afterwards.
This sounds like what python-central implements, except it symlinks rather than copies. The problem is some application packages have an upstream installation layout that places and searches for modules in their own prefered locations, with no consideration for supporting multiple versions of python. This means the packager must either; restructure the layout so that modules are placed in the /usr/lib/python location where they can be symlinked and managed by python-central for multiple versions of python, or just compile the modules in the upstream location so only the default version of python is supported. I suspect that emacs has much stricter and simpler file location rules for emacs scripts, so it can avoid much of these problems. > | I prefer to use the existing dpkg database and package scripts where > | possible, rather than adding extra scripts and/or a "registry". The existing > | dpkg facilities can support this functionality, so why add extra stuff that > | just replicates it? > > unless you ship byte-compiled files in the package, it doesn't. so, > you need to add this stuff one way or another. what I meant was the functionality can be implemented inside the postinst/prerm scripts without adding additional scripts for every package. Admittedly the postinst/prerm scripts get pretty complicated, which is why python-central helps by providing supporting scripts to do it all. -- ---------------------------------------------------------------------- ABO: finger [EMAIL PROTECTED] for more info, including pgp key ----------------------------------------------------------------------
