Re: slib and Schemes
Nick Gasson <nick@nickg.me.uk> writes:
> I experimented with this a bit today, see the catalog-trigger branch
> here:
>
> https://salsa.debian.org/nickg/slib/-/commit/e0c989d60b7
>
> This creates a "slib-catalog" trigger which co-operating Schemes can add
> to their package.triggers file. When run it regenerates the slibcat file
> for each installed implementation. It's similar to what already exists
> in guile-libs.postinst, but centralised in the slib package. Do you
> think this is a good way to proceed?
It's an interesting approach that turns my assumptions on their head. Do
you think it will work better than generating them in the postinsts of
the cooperating Schemes? It'll be easier for you to make sure that it
works in all supported Schemes, but you get more work to do yourself in
slib. Seems like a good idea if it works.
> One (pre-existing) problem is that (require 'new-catalog) will write the
> slibcat file into some implementation specific directory. E.g. for
> mit-scheme it writes to /usr/lib/x86_64-linux-gnu/mit-scheme/slibcat.
> This then generates a warning if mit-scheme is removed later:
>
> Removing mit-scheme:amd64 (10.1.11-2) ...
> dpkg: warning: while removing mit-scheme:amd64, directory '/usr/lib/x86_64-linux-gnu/mit-scheme' not empty so not removed
This sort of thing happens from time to time, but would indeed be good
to avoid.
> I think it would be preferable for the catalog to be placed in some
> directory managed by slib, for example /usr/share/slib/<scheme>/, which
> can then be cleaned up in the prerm script. I've done this for
> chezscheme in the patch above (as it wasn't working in Debian
> previously, so nothing will be broken) by overriding
> (implementation-vicinity) in the .init file.
Is implementation-vicinity used for anything else? If not then it seems
fine, at least for Chez.
(I generally don't understand why slib has such a complicated story for
this catalogue file.).
--
Göran Weinholt | https://weinholt.se/
Debian Developer | 73 de SA6CJK
Reply to: