Unpacking lockfiles in different package managers

[kpcyrd]

On 12/10/25 2:55 AM, John Gilmore wrote:
> Is "lockfile" an appropriate term to use for these files?
> 
> I think of a lockfile as something that avoids race conditions among
> multiple concurrent processes.  As in Wikipedia:
> 
>    https://en.wikipedia.org/wiki/File_locking#Lock_files
> 
> In this repro discussion, a "lockfile" seems to perhaps be "locking" a
> library reference in a compilation to a particular version of that
> library (and sometimes with a particular checksum on that library's
> source code?).  That is an unusual use of the term "lockfile".  I
> wonder if we could consider adopting a less confusing term.
It's a common source of confusion (especially among C developers), but I 
also think this ship has sailed, the term is about a decade old at this 
point.

The oldest reference I could find is Gemfile.lock from 2010, 
composer.lock (2014), Cargo.lock (2015), Pipfile.lock (2015), yarn.lock 
(2016), npm's package-lock.json (2017), .NET's packages.lock.json (2019).

The proper term is "dependency lock file" with plenty of search results, 
I'm surprised wikipedia has indeed zero mentions on this. There's 
https://en.wikipedia.org/wiki/Package-lock.json (which redirects to a 
general npm article however).

Your best bet at this point is probably referring to these files as SBOM 
and hoping it catches on[1]. This is also how I playfully refer to them 
in whatsrc[2]. Using them to specify your build inputs (like cargo and 
friends do, as well as .BUILDINFO) would be much more accurate than 
trying to fuzzy-guess them afterwards.

cheers,
kpcyrd

[1]: Also suggested here almost exactly 3 years ago (back when I was 
still posting there): https://x.com/kpcyrd/status/1601940872484261891
[2]: Random example: 
https://whatsrc.org/sbom/sha256:906399c90831817e64dba301274ee8de9830028f08c2e643e3ee8273df156177