Re: slib and Schemes
Göran Weinholt <goran@weinholt.se> writes:
> Rob Browning <rlb@defaultvalue.org> writes:
>> 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.
>
> For Chez Scheme it would be better to do nothing at all, its compiler is
> very fast. Guile's compiler can take some time, so I guess it would be a
> large benefit to at least do something. But this also speaks against
> this strategy, I've seen *very* slow compilation times with Guile, on
> some libraries. It could quickly make apt upgrade very painful.
I sympathize, though I suspect it might end up being one of the
preferable approaches given all the trade-offs, but we'll see (still
pondering). And I think we'd be able to limit the scope of the
rebuilding when library packages are upgraded (likely to the given
library and all of its reverse dependencies).
For upgrades to the language implementations themselves, in the limiting
case, we'd need to rebuild "everything", but for any particular
implementation, we might be able to do better. For example, I suspect
that Guile would consider it a bug if changes to its own macro
expansions broke APIs in a Z release. So we could choose to skip
rebuilds for those.
> Perhaps in this case it should be rebuilt in the background if that's
> feasible; the user should not wait for it to be completed.
Unfortunately, for Guile specifically, I suspect that won't be feasible,
since it would introduce a race with auto-compilation, i.e. anything
else trying to use the relevant code would either if root, compile to
/usr, or if someone else, to ~/.cache. (Hopefully concurrent
auto-compilations are safe, at least...). But for other
implementations, it might be just fine.
> It's also possible that I'm overthinking everything and we can just use
> the Depends: field and then dig out the dependencies with dpkg. It would
> be more coarse, and would recompile more libraries, but it would have
> fewer moving parts.
Hmm, indeed, at the moment, I suspect this may be preferable.
I'm not familiar with Akku yet (though it definitely sounds interesting)
but at least for Guile, for our purposes I'd think that there may not be
a solid way to collect the right set of dependencies in advance,
i.e. it's entirely possible to do non-declarative imports:
(when weather-is-good?
(import (consult-omens-for-the-list))
I think it might be possible to generate a list of dependencies as a
side effect of executing a program, but that'd only capture the paths
exercised (i.e. a test-coverage-like problem).
Given that, I'd been leaning more toward something like emacsen-common
(though I think we could do something simpler[1]) that just relies on
Debian package dependencies, since they already have to be correct at
their level of granularity (which as you mention, is coarser).
Where feasible, I'd think we should aim to make the harness general
enough to allow implementations sufficient latitude. For example, maybe
Guile ends up not being able to rely on debian triggers for compilation
(perhaps because of the potential for races with auto-compilation), but
if possible, we might not want to preclude other implementations from
relying on them.
All that said, I haven't had time to *really* contemplate what kind of
approach I think might be preferable, but here are a few things I have
been considering: #include <giant-grain-of-salt.h>
Given the variety of Scheme implementations, if it's feasible, I wonder
if we might want more of a callback based approach (that *is* somewhat
like emacsen-common).
Very vaguely speaking (and I assume it'll be more complicated in the
end), we might require libraries to place a file in
/usr/share/debian-scheme/packages/NAME
to opt-in, and imagine the file contains one line for each
implementation it supports.
Then we might require calls in the library maintainer scripts, maybe
they have to call
/usr/lib/debian-scheme/update-library LIBRARY_PACKAGE_NAME
/usr/lib/debian-scheme/remove-library LIBRARY_PACKAGE_NAME
at the relevant points. When called with no args, those would handle
all relevant implementations (listed in the opt-in file).
I suppose we might also end up needing to distinguish install vs upgrade
or...not sure yet (and not critical yet).
Then each scheme implementation would have to provide the concrete
implementations for their part of the work, perhaps via dropping files
into an implementation directory:
/usr/lib/debian-scheme/implementation/guile-install-library
/usr/lib/debian-scheme/implementation/guile-remove-library
...
And finally, the implementations would have some calls in their relevant
maintainer scripts, perhaps something like:
/usr/lib/debian-scheme/install-implementation guile
and
/usr/lib/debian-scheme/remove-implementation guile
which would result in the right (ordered) set of calls to update-library
and remove-library respectively for that implementation.
I'm sure none of that's quite right, and it's definitely too simple, but
perhaps it communicates the general idea. And whatever we do, if we
*do* end up pursuing some "cross scheme implementation" infrastructure,
I think we should try to make the common case as simple as we can
(cf. dh, dh-elpa, etc.), even if we still need to allow additional
complexity to handle some situations.
[1] Right now, I don't think we'll want anything just like
emacsen-common, but it does have some bits we may be able to steal,
like the topological dependency sorting (a tsort hack -- still wish
we had a way to just ask dpkg to sort a given list of packages in
dependency order).
Thanks
--
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: