Feat/cobble

[tarkah]

Resolves #205

Currently cobble installed packages are "ephemeral" and will get dropped on the next sync. Users should add the stones to a local repo to get persistence, or we need to come up with some idea of pinning cobbled stones.

[ermo]

Perhaps my expectations are the issue here, but in my head, the whole point of cobble is to be able to run commands "as-is" on .stones without having to install them?

My test case (which doesn't work):

    Compiling diesel_migrations v2.1.0
    Finished packaging [optimized + debuginfo] target(s) in 3m 19s
ermo@solbox:~/repos/serpent-os/moss [feat/cobble* +4 ~0 -0 !]
$ target/packaging/moss -v
moss 0.1.0 (e0b9035)
ermo@solbox:~/repos/serpent-os/moss [feat/cobble* +4 ~0 -0 !]
$ git log -1
commit e0b903524734d649056b28e18802129b4ef3e630 (HEAD -> feat/cobble, origin/feat/cobble)
Author: Cory Forsstrom <[email protected]>
Date:   Wed Apr 24 13:34:47 2024 -0700

    moss: info: Show info for cobbled stones
ermo@solbox:~/repos/serpent-os/moss [feat/cobble* +4 ~0 -0 !]
$ sudo cp -v target/packaging/moss /usr/bin/
'target/packaging/moss' -> '/usr/bin/moss'
ermo@solbox:~/repos/serpent-os/moss [feat/cobble* +4 ~0 -0 !]
$ moss -v
moss 0.1.0 (e0b9035)
(...)
$ moss info 
font-cantarell-0.303.1-1-2-x86_64.stone  manifest.x86_64.jsonc                    stone.yaml
manifest.x86_64.bin                      monitoring.yml                           
ermo@solbox:~/repos/serpent-os/recipes/f/font-cantarell [autobuild-rebuilds* +2 ~0 -0 !]
$ moss info font-cantarell-0.303.1-1-2-x86_64.stone 
Error: info: client: db: diesel connection: Unable to open the database file
ermo@solbox:~/repos/serpent-os/recipes/f/font-cantarell [autobuild-rebuilds* +2 ~0 -0 !]
$ moss -v
moss 0.1.0 (e0b9035)

[ikeycode]

Yeah the dropping of stones seems wrong to me tbh. Really sideloaded means "i'm pushing this in and above the defaults" so would need the concept of pinning by way of state selections I would imagine. Until the user unpins or restores the cobbled package (ie. "my system is cobbled together from these stones ...") we continue trying to resolve transactions until they inevitably break our dependency graph.

[ikeycode]

A potential "workaround" here actually is layering cobble atop a repo plugin. Such that, any time we "sideload" a stone (or set of stones) we promote from their evaluation site into a staged cobble repository, which just so happens to have a higher priority than everything else.

Eliminates the need for pinning support, and deviates from the apt model by having users pin to a distribution revision or rollback instead.

[ermo]

The only time cobble has interest for me is for when I'm doing quick tests for packaging validation purposes. Hence, to me, cobble should be explicitly designed to support that use-case.

That said, is there a use-case here where we might use cobble to drive bootstrap logic via building "dirty" .stones outside of containment (so using local environment deps instead of boulder-controlled .stone deps)? If so, those are the two use-cases I could see as being useful for cobble.

To me, sideload equates creating a convenient shorthand for using a "normal" local repo and managing that. That might imply that we're better off having sideload actually be a separate "group" of commands (or an alias...?) that copies .stones to the "sideload" (highest priority) local repo? That way, it does what it should, it works with the normal repo plugins and it's controlled by "normal" moss logic re. sync etc.?

I think we need to be very careful re. using the cobble plugin only for very well defined edge cases, such that normal users don't get caught in a trap they can't easily get out of if they use it by mistake -- or because the "sideload" terminology tempts them into building a mental model which is not actually accurate from a moss perspective.

[ermo]

The other option here is that cobble completely removes the need for local repos to be indexed -- cobble takes care of that? In this scenario, cobble actually becomes the mechanism for handling local repos, with the caveat that you can only have one "saved state" of a cobble repo and that's always "what it looks like now". FWIW, this is basically the model Ikey described above (just worded a bit differently) I think?

I'm still on the fence re. which model I prefer; in this scenario, cobble basically replaces the idea of having to manually index local repos?

I have to admit that I haven't quite sussed out the implications of the model where cobble replaces indexed local repos. There's a part of me that insists that this is not a good idea, because it trains users to have the wrong expectations re. how a moss-format repo is managed on a larger scale...

[ermo]

Eliminates the need for pinning support, and deviates from the apt model by having users pin to a distribution revision or rollback instead.

I think we need to accept that with the idea of a versioned recipe repo being brought into being as a versioned moss-format repo revision, we MUST therefore only pin to a distribution revision.

This also has implications for the system-model idea; it would consist of a revision (which could support a special version of ANY, which means "rolling") along with the tags/groups/packages that were valid for that revision. As soon as moss cannot sync to the specified model, it would show the tags/groups/packages that are no longer valid and ask for user input.

FWIW, full-repo revisions (supported by "rebuild until sane" DAG logic) is what Conary did, and it worked brilliantly with the system-model idea.