§Mon
§cabal2opam
it looks like we can use https://hackage.haskell.org/01-index.tar similar to cargo’s package index!
oh no, this is just a bundle of cabal files
also, if we want to depend on projects outside of the repository we’ll need to parse cargo files
§package management abstract
§second year report
§met with anil
package management abstract
- However, inadequacies in software deployment technologies used for spatial devices often leads to scenarios such as running software vulnerable to exploits.
- There is a proliferation of package managers with varying degrees of expressivity and reproducibility using formats that aren’t interoperable.
- Multi-lingual projects can’t provide their dependencies in a unified way, and dependencies from one package manager ecosystem can’t express a dependency on a package from another.
- Language package mangers implicitly, or explicitly in ad-hoc and unversioned mechanisms, depend on system packages.
- There are package managers that don’t support installing previous versions of packages, which in the case of regressions forces a decision between correctness and security.
- Configuration solutions often involve invoking imperative scripts, which are not idempotent, to mutate the state of a system into the desired shape hindering the reliable operation of spatial services.
- % By providing an interoperable and robust software supply chain to our Spatial OS we can ensure the continued secure and reliable deployment of spatial services and devices.
solving
area
Existing package managers are either language or system specific and do not interoperate with each other.
problem
Multi-lingual projects are unable to express a dependency on another language’s library, and system dependencies are typically implicit and unversioned.
solution
We propose a common calculus for package management which is expressive enough for all ecosystems. By writing translations from existing package managers to this calculus we demonstrate how dependency resolution can work across ecosystems.
what this means
This enables a new generation of package mangers using a common protocol that can be hyper-specialised to an operating system or environment.
The lack of a common format hinders the reproducibility and reliability of software supply chains;
Existing package managers are either language or system specific and do not interoperate with each other. Multi-lingual projects are unable to express a dependency on another language’s library, and system dependencies are typically implicit and unversioned. We propose a common calculus for package management which is expressive enough for all ecosystems. By writing translations from existing package managers to this calculus we demonstrate how dependency resolution can work across ecosystems. This enables a new generation of package managers using a common protocol that can be hyper-specialised to an operating system or environment.
billions software supplychain securty other ecosystems paper writing
OOPSLA submission
sigcomm dns capnproto on and off
timetable:
- loco
- package management
DSL over filesystems david jon 1pm tomorrow
part II
bigrapher map
cabal is doing something weird with multiple ‘libraries’ per package
§Tue
§roy bigraph
https://www.cl.cam.ac.uk/research/dtg/archived/files/publications/public/acr31/rice-openroommap.pdf
ctrl Space = 0; ctrl Building = 0; atomic ctrl Person = 1; atomic ctrl Computer = 1; atomic ctrl Empty = 0; big ryan = Person{ryan}; big crt = Computer{ryan}; big fn06 = Space.(ryan); big fn07 = Space.(crt); big fn = Space.(fn06 | fn07); big fs01 = Space.(Empty); big fs = Space.(fs01); big ffloor = Space.(fn | fs); big gn01 = Space.(Empty); big gn = Space.(gn01); big gfloor = Space.(gn); big cl = Building.(ffloor | gfloor); react leave = Space.Person{l} --> Space.Empty | Person{l}; react enter = Space.Empty | Person{l} --> Space.Person{l}; begin brs init cl; rules = [ {leave, enter} ]; end
§second year report
§loco
§go package management
so for go, and node, I’m thinking that we need to push the resolution logic into the solving runtime, PURL/VURL style
we could scrape all the go modules and their transitive dependencies, but we’ll probably hit rate limits
as go projects might have dependencies that we haven’t
§met anil, jon, david, and mark
§Wed
CPAN
go
npm
idris
pacman
portage
package names
for each package name, a set of package versions
for every package version, dependencies
dependencies are a CNF of package versions
- clauses are a set of valid package versions for a package name we depend on
- a clauses could contain packages versions from two packages names if either can satisfy the dependency
- negations of a package version denotes conflicts
a set of package versions forms a dependency graph
taking a view from a subset of this set of package versions is a dependency cone
we can `resolve’ a dependency cone to a set of package versions that satisfy the dependency requirements
package names
for each package name, a set of package versions
for every package version, a set of dependencies.
- a dependency is a package name and a set of valid package versions
for that package
- note: What about OR clauses? Aren’t these are just the same dependency from different sources?
- a dependency is a package name and a set of valid package versions
for that package
for every package version, a list of conflicts
- the inverse of dependencies
- note: do we need these?
a set of package versions forms a directed graph, the dependency graph, where the nodes are package names and edges are dependency relations
we define a transformation from a dependency graph and a set of desired package versions to a set of package versions that satisfies the dependencies
- dependency solving or resolving