Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] RFC: Implementing a "Safe-mode" for Sorcery (was: RFC: Shortcuts for reducing base system breakage)

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Ismael Luceno <ismael.luceno AT gmail.com>
  • To: Remko van der Vossen <wich AT yuugen.jp>
  • Cc: sm-discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] RFC: Implementing a "Safe-mode" for Sorcery (was: RFC: Shortcuts for reducing base system breakage)
  • Date: Wed, 24 Sep 2014 17:36:54 -0300

On Wed, Sep 24, 2014 at 4:09 PM, Remko van der Vossen <wich AT yuugen.jp> wrote:
<...>
> On this note, in the background I have been busy with a castfs
> reimplementation (currently implementing unit testers) which, once
> working properly with the same feature set as current castfs, I would
> like to extend with the possibility of scoping, meaning that within the
> castfs we could limit the filesystem to only those spells mentioned in
> the enabled dependencies (and perhaps basesystem until we have made all
> dependencies explicit.) This will allow us to build inside the castfs
> and thereby track dependencies much better, prevent automagic
> dependencies, and would help us in this case to know what we need.

Sounds good, and the fact that none of the union mount implementations
got merged into mainline so far kind of justifies the effort, yet I
fear this will always be a weak point unless we get other
distributions to use it...

> To be practical though, I think we should just provide a few verified
> and signed tarballs of i686 and x86_64 generic spell caches for the
> build chain. These would be the same ones as available on the ISO. Then
> as long as you have wget and tar (which is needed by sorcery anyway)
> there is always a practical way to get back up and running.

+1.

> In the long run we should focus more on not fscking up the system to
> begin with. We need to be able to cast completely inside stages. That
> includes the build, the dispel and the install, after that we can verify
> the correctness of the build/install if we so desire, and after that
> would be an atomic commit of the updated spell.
>
> Going further one can delay the commit of the updated spell until all
> dependers are also updated in further stages and only commit once
> everything is built, installed and okay. It would even be possible to
> suspend, rewind and replay upgrades, with grimoire updates, sorcery
> updates, reboots, whatever in between before committing the upgrade.
>
> But anyway, for now that is all wishful thinking. As I said before,
> let's first just get through the current upgrades, then start working on
> getting sorcery som stable footing by providing a static environment for
> it to work in and after that start working on our pipe dreams again. One
> step at a time.

+1. One step at a time.




Archive powered by MHonArc 2.6.24.

Top of Page