§Mon
§Package Management
Test with `opam install –dry-run`
you can emulate it by encoding their dependencies and then solving in that order
with a real client, you would just invoke cargo once
cargo depexts
0install
memo bug
getting latest ones
solve for cargo
- equivalent to cargo install
what if we did this for nix flakes? https://github.com/snowfallorg/thaw
§Eon
So, interesting Eon problem: Patrick’s server failed to connect to mine, presumably after a restart of both, as it was querying itself for `freumh.org`:
Aug 05 10:37:31 sirref capd[1761828]: capd: [INFO] Connecting to tcp:freumh.org:7000...
Aug 05 10:37:31 sirref capd[1761828]: +Failed to connnect to primary: Unknown host "freumh.org"
Aug 05 10:37:31 sirref capd[1761828]: +Retrying in 60.000000
I think I’ve just reinvented glue records.
§Tue
§DONE restructure second year report
§KILL submit ASPLOS package management paper
§Wed
§got opam-0install working with constraint solving
trying to see if it working for crossterm ? 0.11.1
§KILL try and add some external dependancies on cargo / opam packages
https://doc.rust-lang.org/cargo/reference/registry-index.html#index-format optional
features calculus
debian format apk format
spin depends on
C:Q1FvuE1cGeU0tdaWgpAvu9PylxewU=
P:aconf-mod-network
V:0.8.1-r2
A:x86_64
S:3953
I:36864
T:Alpine Configurator
U:https://gitlab.alpinelinux.org/kunkku/aconf/
L:BSD-2-Clause
o:aconf
m:Kaarle Ritvanen <kunkku@alpinelinux.org>
t:1673055727
c:cdd3ce01ff79a74ae2e87c50ecdc5bbb358d4df6
D:aconf network
root@a2e42152d552:/# opam install nano
[WARNING] Running as root is not recommended
The following actions will be performed:
- install libc6 2.36-9+deb12u7 [required by nano]
- install libtinfo6 6.4-4 [required by nano]
- install libncursesw6 6.4-4 [required by nano]
- install nano 7.2-1+deb12u1
===== 4 to install =====
Do you want to continue? [Y/n] y
<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
-> retrieved libncursesw6.6.4-4 (http://ftp.debian.org/debian/pool/main/n/ncurses/libncursesw6_6.4-4_amd64.deb)
-> retrieved libtinfo6.6.4-4 (http://ftp.debian.org/debian/pool/main/n/ncurses/libtinfo6_6.4-4_amd64.deb)
-> retrieved libc6.2.36-9+deb12u7 (http://ftp.debian.org/debian/pool/main/g/glibc/libc6_2.36-9+deb12u7_amd64.deb)
-> retrieved nano.7.2-1+deb12u1 (http://ftp.debian.org/debian/pool/main/n/nano/nano_7.2-1+deb12u1_amd64.deb)
-> installed libc6.2.36-9+deb12u7
-> installed libtinfo6.6.4-4
-> installed libncursesw6.6.4-4
-> installed nano.7.2-1+deb12u1
Done.
# Run eval $(opam env) to update the current shell environment
I’ve got a repository at https://github.com/RyanGibb/opam-deb-repository that seems to work! The only issue I’m having is a cyclic dependency between https://packages.debian.org/sid/libgcc-s1 and https://packages.debian.org/sid/libc6… Maybe the debian dependency resolution just prunes cyclic dependencies? I’ve got around it in testing by just removing the libgcc-s1 dependancy from libc6.
Package: libc6
Source: glibc
Version: 2.36-9+deb12u7
Installed-Size: 12986
Maintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org>
Architecture: amd64
Replaces: libc6-amd64
Depends: libgcc-s1
Recommends: libidn2-0 (>= 2.0.5~)
Suggests: glibc-doc, debconf | debconf-2.0, libc-l10n, locales, libnss-nis, libnss-nisplus
Breaks: aide (<< 0.17.3-4+b3), busybox (<< 1.30.1-6), chrony (<< 4.2-3~), fakechroot (<< 2.19-3.5), firefox (<< 91~), firefox-esr (<< 91~), gnumach-image-1.8-486 (<< 2:1.8+git20210923~), gnumach-image-1.8-486-dbg (<< 2:1.8+git20210923~), gnumach-image-1.8-xen-486 (<< 2:1.8+git20210923~), gnumach-image-1.8-xen-486-dbg (<< 2:1.8+git20210923~), hurd (<< 1:0.9.git20220301-2), ioquake3 (<< 1.36+u20200211.f2c61c1~dfsg-2~), iraf-fitsutil (<< 2018.07.06-4), libgegl-0.4-0 (<< 0.4.18), libtirpc1 (<< 0.2.3), locales (<< 2.36), locales-all (<< 2.36), macs (<< 2.2.7.1-3~), nocache (<< 1.1-1~), nscd (<< 2.36), openarena (<< 0.8.8+dfsg-4~), openssh-server (<< 1:8.1p1-5), python3-iptables (<< 1.0.0-2), r-cran-later (<< 0.7.5+dfsg-2), tinydns (<< 1:1.05-14), valgrind (<< 1:3.19.0-1~), wcc (<< 0.0.2+dfsg-3)
Description: GNU C Library: Shared libraries
Multi-Arch: same
Homepage: https://www.gnu.org/software/libc/libc.html
Description-md5: fc3001b0b90a1c8e6690b283a619d57f
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/g/glibc/libc6_2.36-9+deb12u7_amd64.deb
Size: 2757936
MD5sum: a9480b37954b1c6327b09526cc1974c3
SHA256: eba944bd99c2f5142baf573e6294a70f00758083bc3c2dca4c9e445943a3f8e6
Package: libgcc-s1
Source: gcc-12
Version: 12.2.0-14
Installed-Size: 140
Maintainer: Debian GCC Maintainers <debian-gcc@lists.debian.org>
Architecture: amd64
Replaces: libgcc1 (<< 1:10)
Provides: libgcc1 (= 1:12.2.0-14)
Depends: gcc-12-base (= 12.2.0-14), libc6 (>= 2.35)
Description: GCC support library
Multi-Arch: same
Homepage: http://gcc.gnu.org/
Description-md5: bbd60d723e97d8e06c04228ee4c76f10
Important: yes
Protected: yes
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/g/gcc-12/libgcc-s1_12.2.0-14_amd64.deb
Size: 49892
MD5sum: f00018bcad3c773b1fbb378bbdd6b9d1
SHA256: f3d1d48c0599aea85b7f2077a01d285badc42998c1a1e7473935d5cf995c8141
okay, next, try and see if everything is installable
I’m
trying to solve all package versions, but some just seem to be flat out
broken. E.g. https://crates.io/crates/am
depends on owo-colours ^4.0.0 and
color-eyre ^0.6.3, but colour-eyre ^0.6.3 depends on owo-colours ^3.2.0. This bug looks to have been introduced
by a bot https://github.com/ryanccn/am/pull/35
§KILL transform opam-repository depext to depend on debian packages
calculus:
- name
- version
- depends
- sdf
- mechanism? e.g. debian, alpine, cargo etc
- namespacing? urls? domains?
protocol spec, core format, s expressions
§KILL check if cargo installs fail for uninstallable opam ones too
§KILL cudf solve for multiple versions
§Thu
The name mangling is the mechanism used to link multiple versions, and the solver algorithm will select multiple versions there’s an upper bound below an already selected higher version:
The algorithm employed here is fairly simple, we simply do a DFS, activating the “newest crate” (highest version) first and then going to the next option. The heuristics we employ are:
Never try to activate a crate version which is incompatible. This means we only try crates which will actually satisfy a dependency and we won’t ever try to activate a crate that’s semver compatible with something else activated (as we’re only allowed to have one) nor try to activate a crate that has the same links attribute as something else activated.
Always try to activate the highest version crate first. The default dependency in Cargo (e.g., when you write foo = "0.1.2") is semver-compatible, so selecting the highest version possible will allow us to hopefully satisfy as many dependencies at once.
Beyond that, what’s implemented below is just a naive backtracking version which should in theory try all possible combinations of dependencies and versions to see if one works. The first resolution that works causes everything to bail out immediately and return success, and only if nothing works do we actually return an error up the stack.