Wrong purl to url conversion for debian

[vargenau]

In the spec, https://github.com/package-url/purl-spec there is an example of Debian PURL:

pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie

packageurl-python converts this PURL in the following URL:

https://deb.debian.org/debian/pool/main/c/curl/curl_7.50.3-1_i386.deb

This gives:

The requested URL was not found on this server.

[gdahlm]

This is not a solution but may inform why this isn't possible for those who are steered in this direction by the ecma-427 standard example that is above.

With PURLs this is not a bug, and while you may be able to reverse the transformation for some repo types, with Debian repos, and especially using the example in the ecma-427 standard it should not be possible to do reliably.

A PURL shall not contain a URL Authority, i.e. there is no support for username, password, host and port components. A namespace segment may sometimes look like a host, but its interpretation is specific to a type.

While there are some really really simple Debian repos, like nvidia which are flat:

.
├── debian13
│   └── x86_64
│       ├── cuda-13-1_13.1.0-1_amd64.deb
│       ├── InRelease
│       └── Packages
└── ubuntu2404
    └── x86_64
        ├── cuda-13-1_13.1.0-1_amd64.deb
        ├── InRelease
        └── Packages

The process still depends on the ephemeral indicies, where InRelease points to files Packages(.gz|.xz) indicies which hold the path to the actual package.

In the larger Debian/Ubuntu repos, ${root}/dists is where the indicies live, and ${root}/pool is where all the actual package files live for all releases.

.
├── dists
│   ├── bookworm
│   │   ├── contrib
│   │   │   ├── binary-all
│   │   │   │   └── Packages.xz
│   │   │   └── binary-amd64
│   │   │       └── Packages.xz
│   │   ├── InRelease
│   │   └── main
│   │       ├── binary-all
│   │       │   └── Packages.xz
│   │       └── binary-amd64
│   │           └── Packages.xz
│   ├── bullseye
│   ├── Debian11.11 -> bullseye
│   ├── Debian12.13 -> bookworm
│   ├── Debian13.4 -> trixie
│   ├── experimental
│   ├── forky
│   ├── oldoldstable -> bullseye
│   ├── oldstable -> bookworm
│   ├── rc-buggy -> experimental
│   ├── sid
│   ├── stable -> trixie
│   ├── testing -> forky
│   ├── trixie
│   └── unstable -> sid
└── pool
    ├── contrib
    │   ├── a
    │   │   ├── a-el
    │   │   └── a2d
    │   ├── b
    │   └── c
    └── main
        ├── a
        │   ├── a-el
        │   └── a2d
        ├── b
        └── c

As the paths under pool may change due to provider needs to balance directory sizes, and as package files that no longer are referenced are often deleted or moved to archive servers, any URL that a tool like packageurl-python produced from a PURL would be unreliable.

As a more concrete example:

If you look at the Nvidia example above, cuda-13-1_13.1.0-1_amd64.deb exists in both the ubuntu and debian versioned directories, that would match the pkg:deb/nvidia/cuda-13-1@13.1.0-1?arch=x86_64 pattern but as they don't even have a jessie codename dir, that part of the PURL doesn't help you.

In my experience the PURL spec works well for repos that are backed by an object store, where package name + version is just a reference to a UUID or Hashed object name. As long as the vendor maintains their side of the contract.

But the contract with Debian repos is the uniqueness of the entire filename, with the package name being unique per major distro.

TL;DR

Purl's are a one way function, while some repo types may allow for reversing, it will not work with Debian repos, and the offical example doesn't even maintain that contract.

If you ignore the simplified example in the standard and use {pkg_name}_{version}-{deb_revision}_{deb_arch}{.deb|.tar.gz|...} you are closer to the contract that Debian repo providers are offering.

You could capture the pool path when you download it and include it in the purl's optional fields, but there is not promise let alone guarantee that that URL will be valid when you try to use it.

Hopefully the standards documentation and additional documentation makes this clearer in the future.