§Mon
§package management paper
DONE cite go rox blog post
DOING add citations for all package managers
DONE syntax -> bundle format
DONE vesion formula
DONE src vs bin -> binary caching in features column
DONE repo release in description; ecosystem and name together
DOING add order of magnitude packages (and order by)
DONE packaging language
cabal - https://cabal.readthedocs.io/en/stable/cabal-package-description-file.html#package-descriptions packaging language - dsl or edsl (with power of host language) DSL/eDSL
DONE add sandboxing field
DONE add subsections links to section 2
DONE add dune
DONE add B/P/C to toolchain field
DONE concurrent versions - be clear about solving
DONE Resolution hypergraph annd Resolved graph
DONE tigher footnotes
DONE binary bundles and provisioning, reorder figure 1 before table to talk about provisioning
DONE section 4: onramp - language and bundle; formalisation; offramp
KILL section 6: use to provide rust packages https://doc.rust-lang.org/cargo/commands/cargo-vendor.html
DONE solving instead of resolving?
Exponentials sound sciency Reify
§Tue
§package management paper
DONE inline figures
KILL debian supports OR version formula
§Wed
§package management paper
§Thur
§package management paper
typos
DONE opam dependency formula variables
DONE provision network requests
KILL thinking about it, I actually think the opam file format is more of a packaging language and less of a bundle
CANCELED replace deployment section with related work
DONE 5.1 then go home
§Fri
§package management paper
I’m thinking about whether we really need to define ecosystems as a bigraph; we don’t use the motion part of bigraphs
Unless… we can express resolving as a BRS?
issues:
we want to track the resolved graph, not just the resolved set of packages, so that we know which package satisfies a dependency if multiple show up in the graph
e.g. if we have deps(a)={{b, c}} but the SAT encoding to solve the edges is probably inefficient
boolean logic representation in the hypergraph and SAT encoding is probably inefficient
how does the zeroinstall solver do it?
a first-class feature resolution encoding – and could this subsume optional dependencies
how could we represent this in SAT?
patrick: it’s meant to show how we unifiy all of these things NOT BE FAST
and be simple in it’s use of mathmatical objects Features are just an exponentuial blowup of the versions rust can install. E.g. the unificaition is the exposion.
exloring the feature space and pulling out the commonalities
not build a real system
§Sat
§package management paper
diagramming et all
§Sun
§package management paper
DONE feedback on 4.1
DONE boolean diagram
Nix service deployment
Basically, Nix is a great deployment model but suffers from a bad language and non-FSH.
what if we had a cross-ecosystem way of describing dependencies and then different backends for deployment on different systems
DONE fill in sandboxing
DONE patrick simplify the conflicts to be conflict sets
DONE capitalize figure
DONE section 5
DONE cargo features optional deps
CANCELLED cargo features can we have multiple feature sets?
CANCELLED 4.2.1 version ordering zeroinstall SAT and cost function opium/cudf
idea around more efficient SAT solving
DONE conflict set clarification
CANCELLED diagram full page
DONE opam-giga-repository numbres
DONE fix figure 1 - waiting for patrick
DONE conclusion (kinda)
DONE data availability statement
CANCELLED re-read section 4.3.2
DONE abstract
KILL table 1 with numbers and citations
KILL proof read
future thoughts: cost functions, SAT performance, providing packages, ecosystem translations, hyper-specialised package managers