Dependency Tracking is Hard
28 points by dhruvp
28 points by dhruvp
lol, do none of those "dependency trackers" know about dpkg, RPM, ports, Nix, etc.? They were the OG "package managers", before the term got co-opted by narrow "compiler input choosers".
They do. I think this article is complaining about the inability of these tools (and specifications like PURL) to track bundled dependencies that are vendored with a project or OS, not packaged via a recognized package system.
That doesn't make sense; Debian doesn't "vendor" curl. They package it normally in a way that makes it very clear what its dependencies are: https://packages.debian.org/sid/curl
The provided screenshot in the article ignores this fact for some reason; perhaps because the set of package managers they support does not include apt which is weird because it's one of the most widely-used package managers in the world.
I find this wording very strange, where a software "supports" package managers like apt or even is expected to. Very few software I use maintains apt repositories upstream or provides distro packages, regardless of the distros' popularity.
I'm not following. For tracking bugs and vulnerabilities across dependency graphs, why is it relevant whether the packaging work is performed by the maintainer of the project vs a distro packager? In either case you need to know what you depend upon and what it depends upon and what problems might be lurking there.
I believe I misinterpreted your comment and thought "they" in "the set of package managers they support" means the curl project, not GitHub.
The PURL specification mentions that it uses the pkg URI scheme, but this is not a registered URI scheme. It looks like attempts to register the scheme encountered problems during review that remain unresolved.
We can’t specify curl or libcurl using a PURL.
I'm not sure if that's as a response to this post, but PURL shows 3 examples of curl definition in its readme right now. Edit: it's not new, the most recent format of the curl line is from 2018 https://github.com/package-url/purl-spec/commit/91e056360db01b76581164c3a284de6fdffecfc0#diff-7b3ed02bc73dc06b7db906cf97aa91dec2b2eb21f2d92bc5caa761df5bbc168fR114
The point is that PURL confuses a package for a dependency.
I'm not sure why you think they confuse anything. They wrote a spec for identifying packages and that's what the result does. If you're actually interested in tracking the details for sbom level documentation, "depends on curl" means nothing - you want "uses curl-1.2.3 released in redhat FooBar edition repository".
(Which also leads to C style dependencies not being automatically included. Wanna parse a "configure" script statically to identify if a given dependency is required?)
Or my other favorite version of this problem: when the tools scan the filesystem looking for declarations of dependencies versus "yes, I see you actually have do have libcurl-8.18.0-4 in /opt/rando/lib and didn't do a $(rm -rf /var/lib) before shipping your docker image"