Re: dependencies of non-module packages
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 abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Reply to: