Re: slib and Schemes
Hi Göran,
On 09/23/20 01:12 am, Göran Weinholt wrote:
>>
>>> 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?
>
> Nick: If slib is ready for Guile 3.0 in your opinion then please file a
> wishlist bug on guile-3.0-libs asking for it to be enabled in the
> postinst.
>
>> 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.
>
> Agreed. I think the way that it's done in guile-libs.postinst should
> work.
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?
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
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.
--
Nick
Reply to: