This isn't intended for / usage right?

@alatiera You removed your comment so we don't really have an answer to this.

@ikey from glancing around the docs and what I remember of previous openSUSE use, it is intended for / usage. Or, at least, it can be used on / and is used in such a way by openSUSE, e.g. in case a system upgrade goes awry.

On the tutorial page, for instance, the first example config shown is for /. Also, item #8 on the FAQ says:

After you have installed snapper packages, you will have to create a config for your root filesystem by calling:
snapper create-config /

Hope that answers the question.

In that case I'm not sure how it applies to Solus right now. Our installer doesn't support btrfs, and likely never will. Unless it can support non-btrfs then I *suppose* but it seems a bit pointless.
Someone give me a use case here applicable to Solus. :)

It also works with lvm, but it depends on thin-provisioning.

Solus supports btrf and snapper helps to make snapshots easier, so why not implement it. You can use it on / but you can also use it on every directory

so why not implement it

Because we don't support BTRFS. If anything, we discourage it. We don't support it in the installer and I can't imagine the potential breakage that occur if / when we do kernel rollbacks (which we're able to do and I believe we've done in the past).

Sorry for reviving this so late. The use case I can imagine, and why I currently use openSUSE, is that if something breaks on upgrade, you can rollback to the last state in which your system was still good. From my understanding also, you can use Snapper to determine exactly where the problem was, and therefore make it easier to debug. I don't personally have experience on that.

It may not be reasonable to use Snapper, as it requires btrfs, but can this be done in the package manager, with eopkg? With the conary package manager, if there was an upgrade that broke something in your system, you could do a package management rollback to achieve the exact same state of packages prior to the breakage. Some package managers have rollbacks, but they do not duplicate the exact state before the breakage, and therefore something can still be broken.

If an upgrade breaks in Solus, will an eopkg rollback produce the exact state of packages prior to the rollback? If so, maybe just adding a section into the Software Center that documents the history, and allows for rollbacks - similar in function to Snapper, but very different in implementation. The pisi package manager did have a section for rollbacks on their GUI, but I never knew much about their actual capabilities.

This is obviously not the same as the original request, but it would at least help with the one use case of handling breaking upgrades. For rolling releases, this seems really important to me.