16 Sep 2024

Previous: 9 Sep 2024 Next: 23 Sep 2024

  1. Mon

    1. cabal2opam

      1. it looks like we can use https://hackage.haskell.org/01-index.tar similar to cargo’s package index!

        1. oh no, this is just a bundle of cabal files

        2. also, if we want to depend on projects outside of the repository we’ll need to parse cargo files

    2. package management abstract

    3. second year report

    4. 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

      1. area

        Existing package managers are either language or system specific and do not interoperate with each other.

      2. problem

        Multi-lingual projects are unable to express a dependency on another language’s library, and system dependencies are typically implicit and unversioned.

      3. 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.

      4. 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.

      5. 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

      6. cabal is doing something weird with multiple ‘libraries’ per package

  2. Tue

    1. roy bigraph

      1. 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

    2. second year report

    3. loco

    4. go package management

      1. so for go, and node, I’m thinking that we need to push the resolution logic into the solving runtime, PURL/VURL style

      2. we could scrape all the go modules and their transitive dependencies, but we’ll probably hit rate limits

      3. as go projects might have dependencies that we haven’t

    5. met anil, jon, david, and mark

  3. 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?

    • 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

  4. Thu

    1. https://github.com/mt-caret/polars-ocaml/pull/94

    2. package management calculus

    3. issue with deb provides mechanism: we can’t depend on virtual packages if we don’t create them

    4. ~ get install graph from 0install

    5. getting

  5. Fri

    1. worked on core calculus

    2. ~ re-introduce Debian virtual packages as cargo/opam might depend on them

  6. Sat

    1. It’s a hypergraph!

    2. OPM: An Ontology-Based Package Manager for Building Operating Systems

  7. Sun

    1. Wrote up the dependancy calculus with a hypergraph formalisaion and did an NP-complete proof.