Public SourceMage Discussion List

[Thomas Orgis <thomas-forum AT orgis.org>]

Am Wed, 31 Oct 2018 04:37:01 +0100
schrieb Remko van der Vossen <wich AT yuugen.jp>: 

> Last year I was busy with developing something similar, the main
> differences are:

I remember that. You had quite a bit of work there.

> - outside of Sorcery as a grimoire function, i.e. doesn't require a
>   sorcery release and/or update by the user

My main gripe would be that: This is core functionality of the package
management. We would not implement castfs in grimoire … preventing ABI
breakage, working around cyclic dependencies … things that sorcery
should do.

This stuff you want for all spells from all grimoires. Having possibly
multiple implementations of that core functionality around via multiple
grimoires does not look right to me. What is preventing us from making
a sorcery release from time to time? Once we rely on a feature that was
devel/test sorcery for a while and now entered stable, the grimoire
shall request a minimum sorcery version. Admin Mage can update sorcery,
then continue.

I see a point to have CMake, scons, specific CPAN/Qt/… functions in the
grimoire, not bothering sorcery with every whim of build system out
there. But the option to not break the system when updating isl, icu,
curses should not depend on a hack in FUNCTIONS. I like the idea of it
being implicit for spells. If there is libfoo.so.y now instead of
libfoo.so.x before an upgrade, preserve libfoo.so.x (be it in a special
spell or in a database that later cleanse can work with).


> - move the necessary libraries (or any other files for that matter) to a
>   special "preservation" spell, i.e. no aliens released to the wild.
>   The "preservation" spell can be dispelled when no longer needed

This is a nice approach … offers the same result as mine and does not
rely on anything else than cast/dispel to keep a system clean. That is,
as long as the list of preservation spells is easily reportet for the
Mage to work with.

> I had this largely working, but didn't have time to do the final ironing
> out. I would be very interested in pursuing this further though.

Well, maybe that work can be reactivated. I do not care that much about
which approach is chosen in the end. Mine seems rather trivial for the
basic feature of not deleting the old libs. But my proposl is
incomplete: I only record the information necessary for cleanup. There
is no actual cleanup code.

> Some of the grimoire functions I made are very, very hackish, mostly due
> to the lack of native support in Sorcery for what I'm trying to do.

Let's make sorcery support that stuff natively!


Alryghty then,

Thomas