Re: slib and Schemes
Nick Gasson <nick@nickg.me.uk> writes:
> I verified the latest release with scm, mit-scheme, and guile. Guile and
> MIT need to have slib loaded once as root in order to generate the
> catalogue file (there's a bug for this already). As I mentioned before I
> think the solution is to generate the catalogue for each Scheme
> implementation using a trigger in the slib package, but I haven't
> started working on this yet. Do you think that's a good idea?
Offhand, I'd imagine either a trigger or some other maintainer-script
based approach to keep the file up to date would be appropriate.
I don't know enough about the requirements to have any solid idea
personally, but I'd guess triggers would be preferable if they'll suit,
i.e. do they run often/soon enough with respect to either slib and/or
the various scheme implementation upgrades.
At least for guile, unless slib is also going to ship the compiled ".go"
files, we might have some additional questions (that apply to all
"add-on" packages).
Using guile as an example, ideally, we probably don't want to
rely on guile's auto-compilation for our packaged .scm files since that
will end up compiling each .scm file whenever it's first loaded (or the
timestamp changes), per-user, to XDG_CACHE_HOME, i.e. ~/.cache/...
Macros raise another concern since guile has no automatic dependency
tracking for them right now. Conceivably whenever a guile add-on
package X changes (say slib), every other add-on package that depends on
it may need to be completely recompiled, immediately, and in a way that
avoids any auto-compilation.
While I'd much prefer to avoid the complexity, those two considerations
might mean that what guile really needs is something similar to the
debian emacs infrastructure, which automatically byte-compiles add-ons
at install time whenever emacs is updated, *and* whenever a dependency
changes. No idea if other schemes have similar considerations.
We might also be able to do something simpler if more expensive (maybe
a lot more), than emacsen-common. For example, we might be able to just
disable byte-compilation during package installs/upgrades, delete *all*
the compiled files from any package's preinst, and rebuild the world in
a final trigger.
We could also just rely on auto-compilation, and accept the wasted
space, longer initial startup-times (per user after an upgrade), and
potential risks related to changes in macros, but that's perhaps not
ideal.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Reply to: