purl-spec
purl-spec copied to clipboard
package-url
Purpose of distro qualifier for Debian packages?
I don't understand the purpose of the "distro" qualifier for Debian packages. If I'm not completely mistaken, Debian and derivates use a shared package pool for all distribution releases, so e.g. jessie and stretch can share a completely identical package.
In turn, this means that namespace, name, version plus the arch qualifier fully describe a Debian package. So the distro qualifier should be optional.
This also means that the note "There is no default package repository:..." should state the the repository url should be derived from the namespace, not the "distro" qualifier.
(In contrast, RPM-based distributions have distinct package repositories for each release, so the distro key is necessary there!)
@gernot-h your statement is right, packages are in a pool that is common to all the releases of a distro being provided by the corresponding repository. It can even be referenced by derived distros (like Ubuntu).
Those packages available in the pool are then referenced by distro specific files (Packages).
I think I mentioned this on the initial draft, the "distro" qualifier might be relevant depending on the purl usage.
While it's true that the vendor + package-version-arch should be enough to uniquely describe a package in Debian, the distro qualifier still provides possibly relevant information, which might otherwise not be available. For example, as has been mentioned, the same version might be present in multiple releases through a shared pool, but some security bugs are relevant only in specific contexts when combining such packages with another given set of packages. This might also convey a package in that specific release, which would have security support, in contrast to an earlier release where that might not be the case (even if they are at the same version).
But then the fact that Debian currently uses a shared pool is IMO an implementation detail of this specific project, and something that has not always been the case (older releases didn't, as can be seen from http://archive.debian.org/), which does not directly translate to any deb-based distribution or derivative, which could have separate pools too, or similar.
In addition, for the case given above, about archived releases, you do need the qualifier otherwise you might try to search in the usual mirrors which might not have the package available.
Not sure whether these are good enough reasons though. :)
I think that @guillemj has a point, but @gernot-h too...
I see here the same conflict as between content-addressed and location-addressed storage. The problem is that they are orthogonal and both relevant. In some cases you want to "refer" to the bits of a package (you then care only about the content) and in some others you want to consider also its context (then you also care about the location). IMO it should be possible to refer to then both ways... But how? As mentioned above, I'm not an expert in PURL :slightly_smiling_face:
I don't follow PURL that much, but I haven't found any reference to the existence of alias or similar. Because that would be probably the solution.
On the other side, the PURL of an official debian package without distribution and release is sort of content-addressed, because any change in the content of such a package requires a new package version. But what if a debian package with exactly the same name and version but a change in a single bit gets hosted somewhere else (e.g. a Repo from Ubuntu)? It means that adding somehow the information "this is an official debian package" is required...
Rereading what I've written above, I'm not sure that I've written something understandable :disappointed: Hope so though
Thanks, @guillemj and @Silvanoc for your answers! I can see your point - and it gets even more confusing taking into account @Silvanoc's comment regarding hosting, because https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#deb states: "There is no default package repository: this should be implied either from the distro qualifiers key or using a base url as a repository_url qualifiers key". According to this, a Debian purl is not really fully qualified without "distro".
As we also have the namespace part which clearly differs between pkg:deb/debian/[email protected] and pkg:deb/ubuntu/[email protected], I would however argue that at least for the "debian" namespace, the repository is actually defined, even without any "distro" qualifier.
If Debian indeed used distro-specific repositories in past and we only speak about a current "implementation detail", then we can probably safely close this issue. I however thought that a shared pool is a fundamental design decision at Debian - and when looking at http://archive.debian.org/debian/pool/main/, I still can't see that it was split in past?
@gernot-h see for example: http://archive.debian.org/debian/dists/bo/main/binary-i386/base/ or http://archive.debian.org/debian/dists/hamm/hamm/binary-i386/editors/. The shared pool was en explicit decision when that change was designed, but I don't think it's something that's set in stone, as the move from the old layout to the shared pool was transparently implemented thanks to the indirection from the Packages and Sources metaindices. I'm not currently seeing any reason to change the shared pool design in Debian, but then new needs might arise that might prompt further changes in the archive layout, so one never knows. :)
@gernot-h see for example: http://archive.debian.org/debian/dists/bo/main/binary-i386/base/ or http://archive.debian.org/debian/dists/hamm/hamm/binary-i386/editors/.
Thanks! At those times I was busy changing floppy disks and cdroms while installing S.u.S.E. Linux and had no look on Debian yet. ;)
So we probably indeed have good arguments for and against the current implementation and we better not change it without clearly better reasons?
Closing this based on @gernot-h's last comment. Feel free to re-open if opinions have changed.
