Re: slib and Schemes
On 10/15/20 00:28 am, Göran Weinholt wrote:
> Nick Gasson <nick@nickg.me.uk> writes:
>
>> On 10/08/20 23:56 pm, Göran Weinholt wrote:
>>>
>>> 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.
>>
>> I'm not sure which way is best. It seems the same code either needs to
>> all go centrally in the slib postinst or distributed in each Scheme's
>> postinst. To me it seems more straightforward to put it all in the slib
>> package, as the logic is largely the same for each Scheme and it makes
>> tasks like moving all the catalog files to a central location easier.
>
> All good points. And if it breaks, it is slib that got broken and the
> bug will be filed against slib, which seems very appropriate. If you
> think that you can make it work then I'm all for it, at least as
> maintainer of the chezscheme package.
I've been experimenting with this a bit more recently with a view to
updating the slib package. The interactions between the trigger and the
postinst scripts in each Scheme package can be quite complicated and
fragile so I've been trying to think of a simpler solution.
As the catalog files are essentially a static table of which slib
modules exist with minor customisation for each Scheme, I think they
could be generated once at build time and shipped as part of the slib
package, rather than regenerating it on the user's machine each time.
The slib package would then Build-Depend on all the supported Schemes,
generate the slibcat for each Scheme in debian/rules, and then install
them under /var/lib/slib/<scheme>/slibcat. The (implementation-vicinity)
function would be overridden to return /var/lib/slib instead of the
upstream default. This means we don't need to add triggers or run any
Scheme code in postinst.
SCM is a bit special as it depends on slib and also ships a mkimpcat.scm
which customises the catalog, so it can stay as it currently is. But I
think the proposal above will work for the other Schemes in Debian (none
of which work at present without the user doing (require 'new-catalog)
as root). And it doesn't require any changes to packages other than
slib.
What do you think?
--
Thanks,
Nick
Reply to: