An incredibly dumb grepping of the opam-repository repository revealed something like ~300 opam files across 67 projects mentioning tarballs previously hosted by bitbucket.org, which indeed are all gone at this point:
$ grep -RE 'bitbucket.org.+\.tar' . | grep -Po '(?<=./packages/)([^/]+)' | uniq
opencc
planck
trie
conjury
ppx_poly_record
unmagic
ppx_integer
camlon
bitstring
ppx_monadic
nlopt-ocaml
ibx
oth
opencc0
ppx_implicits
pvem_lwt_unix
ppx_overload
ppx_orakuda
levenshtein
meta_conv
nonstd
ppxx
lua_pattern
opencc1
charInfo_width
tidy
pvem
spotlib_js
gnuplot
sibylfs-lem
gadelac
ppx_test
ppx_sexp
treeprint
typpx
ppx_dotbracket
minimal
azure-cosmos-db
orakuda
pa_monad_custom
ocamldap
macaque_lwt
opamfind
libsvm
ocaml-indent
spotlib
tcx
ppx_meta_conv
pds
docout
camlimages
oni
snabela
mmseg
tiny_json
revops
ppx_curried_constr
tiny_json_conv
ppx_pattern_guard
spotinstall
ocamlspot
hll
orsetto
dune_watch
merlin-of-pds
pa_ovisitor
sosa
- I wonder if there is a “safe” place that’s been set aside for such orphaned libraries to be relocated to (presuming tarballs matching the published hashes are recoverable somewhere)?
- Given the inevitability of broken links like this (and also the security implications of package repositories not retaining released artifacts themselves, immutably), has there been any consideration of having the opam repository capture and retain tarballs permanently? I know this is a bit off topic for this thread, but seeing changes like this (where both upstream tarballs and their hashes are being changed) gives me flashbacks to some bad old days with Maven, npm, and PyPI when those package managers had a similar laissez-faire approach to artifact retention and integrity.
[edit: I posted a more comprehensive question on the topic of opam’s security posture and data integrity policies: Opam-repository: security and data integrity posture]