Support for distribution-specific pool directory in Debian

balasankarc · August 25, 2025, 5:47am

I am working for an ISV (Independent Software Vendor) who produces packages for
their platform-native product. Each release will create packages for Debian
Bookworm, Debian Bullseye, and Debian Trixie. All three packages will have same
name, version, and architecture. And following the Debian naming standard, all three
files will be named the same - component_1.0.0_amd64.deb. However, the contents of these
packages will be different, as they contain platform-native libraries in them.

Due to how Debian repository’s flat pool structure works, when trying to
upload the package to same repository but to different distributions, the files
(having same filename) will overwrite one another in the pool directory.
This is because the path will be
/debian/pool/main/c/component/component_1.0.0_amd64.deb.

Is it possible to somehow split the pool directory based on distributions (in
addition to component) so that package of each distribution go to its own
unique path and won’t conflict with package for another distribution?
So the path will be something like /debian/pool/<distribution>/main/c/component/component_1.0.0_amd64.deb.

If not, are the following the only ways to work around this?

Make each distribution essentially a Pulp repository, so that each of them
gets their own dists and pool directory.
Include distribution version in the package version (similar to the rpm
world), so that file names will be different and won’t overwrite.

Few other commercial products that I checked out did the
“split-pool-directory-per-distribution” logic. And I wanted to check if Pulp
also could do something similar.

PS: I am a Debian Developer, and I am very well aware of how Debian in the past
had distribution-specific locations for storing package files and why it was
moved to a global, flat level pool directory structure. But, given this might
be the case for other ISVs who produce similar packages, I wonder what is normally
done in these scenarios.

PPS: I found

github.com

pulp/pulp_deb/blob/556985852df46cd792a6d5904fe260ec4bbb87a3/pulp_deb/app/models/content/content.py#L73-L91

    
      
          def name(self):
              """Print a nice name for Packages."""
              return "{}_{}_{}".format(self.package, self.version, self.architecture)
          
          
def filename(self, component=""):
              """Assemble filename in pool directory."""
              sourcename = self.source or self.package
              sourcename = sourcename.split("(", 1)[0].rstrip()
              if sourcename.startswith("lib"):
                  prefix = sourcename[0:4]
              else:
                  prefix = sourcename[0]
              return os.path.join(
                  "pool",
                  component,
                  prefix,
                  sourcename,
                  "{}.{}".format(self.name, self.SUFFIX),
              )

which computes what the path should be and

github.com

pulp/pulp_deb/blob/556985852df46cd792a6d5904fe260ec4bbb87a3/pulp_deb/app/serializers/content_serializers.py#L502

    
      
              if artifact_dict and self.instance.sha256 in artifact_dict:
                  artifact = artifact_dict[self.instance.sha256]
              elif remote_artifact_dict and self.instance.sha256 in remote_artifact_dict:
                  artifact = remote_artifact_dict[self.instance.sha256]
          
          
    if artifact:
                  ret.update({"MD5sum": artifact.md5} if artifact.md5 else {})
                  ret.update({"SHA1": artifact.sha1} if artifact.sha1 else {})
                  ret.update({"SHA256": artifact.sha256})
                  ret.update({"Size": str(artifact.size)})
              ret.update({"Filename": self.instance.filename(component)})
          
          
    return ret
          
          
class Meta(SingleArtifactContentSerializer.Meta):
              fields = SingleArtifactContentSerializer.Meta.fields + (
                  "package",
                  "source",
                  "version",
                  "architecture",
                  "section",

which puts that value in the Packages file. I am also wondering if I can
somehow patch those lines in my Pulp instance to include the distribution name
also in the pool path.

quba42 · August 25, 2025, 8:20am

I am going to quote the Debian Repository Format article on “duplicate packages”:

A repository must not include different packages (different content) with the same package name, version, and architecture.

If your ISV’s packages contain different content, then the only correct thing to do, is to either consider them a different version of the same package, or to consider them different packages. They should either have different names or different versions for the different distributions/releases.

If they are the same package, containing the same version software, but somehow different builds, note that the version may be structured as <software_version>-<revision_version>, see 5. Control files and their fields — Debian Policy Manual v4.7.2.0 for more. BuildingFormalBackports - Debian Wiki might also provide example versioning conventions for specific workflows.

Bad practice workaround: If your ISV insists on not versioning their packages correctly (which may make it impossible for apt to correctly upgrade a system for example from bookworm to trixie), then they need to use different pulp_deb repositories for the different distributions/releases, because pulp_deb specifically validates for (and forbids) duplicate packages (defined as same name, version, and architecture, but different checksum) in a single repository.

balasankarc · August 25, 2025, 12:06pm

@quba42 Thanks. I did guess that would be the case, as our use case is very non-standard.

I am trying to migrate from a proprietary solution which supported this to Pulp, and wanted to make it as much as free-of-breaking-changes to our users - so that their existing sources.list files and apt install commands work. Maybe using the Debian revision field is the way forward.