On Sun, Sep 08, 2002 at 02:49:24PM +0200, Tollef Fog Heen wrote: > * Graham Wilson > > | On Sun, Sep 01, 2002 at 09:08:36AM +0200, Tollef Fog Heen wrote: > | > Until dpkg supports triggers, I think what the emacsen does it the > | > most sane -- I'd be really, really happy if python modules/apps were > | > | what do the emacsen do? > > Each package provides a shell script which byte-comiles the package's > files. If a new emacsen is installed, it will call emacsen-install, > which in turns calls each of the already-installed extension packages' > install script. > > 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? Can emacs support parallel installation of multiple versions of emacs? Where are the compiled files kept for each installed version? 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? > One has a similar emacs-remove script, which removes the byte-compiled > files, either when an emacsen is being uninstalled or the package > itself is being uninstalled. 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? -- ---------------------------------------------------------------------- ABO: finger [EMAIL PROTECTED] for more info, including pgp key ----------------------------------------------------------------------
