An additional character "1:" is being added after the (_)underscore with the filename of Ubuntu (deb) package in Pulp3 repository.

[manish-nuance]

Version
Please provide the versions of the pulpcore and pulp_deb packages in use, and how they are installed. If you are using Pulp via Katello, please provide the Katello version.

pulp-cli 0.22.0
pulp-cli-deb 0.0.5
pulp-deb 3.1.1
pulp-file 1.16.0
pulp-glue 0.22.0
pulp-python 3.11.0
pulpcore 3.43.1

Describe the bug
A clear and concise description of what the bug is.
I encountering an issue with the filename of a Debian (deb) package in a Pulp 3 repository, where an additional character "1:" is being added after the underscore.

Actual deb package name in Source (remote) location:
http://us.archive.ubuntu.com/ubuntu/pool/main/libx/libxcomposite/libxcomposite1_0.4.5-1build2_amd64.deb

Sync and Published deb package name in pulp3 repository: (Adding 1: character after underscore in filename)
http://x.x.x.x:24816/pulp/content/prod/ubuntu/2204/pool/main/libx/libxcomposite/libxcomposite1_1:0.4.5-1build2_amd64.deb

To Reproduce
Steps to reproduce the behavior:
pulp deb repository sync --name <deb_repo_name> --mirror
pulp deb publication create --repository <deb_repo_name> --structured --version 1 --signing-service 'Pulp QE'
pulp deb distribution update

Expected behavior
A clear and concise description of what you expected to happen.

The pulp3 published repository package name should be same as source(remote) deb package name.. should add any additional characters..

Additional context
Add any other context about the problem here. Please provide links to any previous discussions via Discourse or Bugzilla.

[quba42]

By design, pulp_deb will publish packages using filenames that use a standard naming scheme.
See also: https://github.com/pulp/pulp_deb/blob/main/pulp_deb/app/models/content/content.py#L76

This means the filename may be different from the repo you synced from (or from what you uploaded). In this case, the upstream repo did not include the epoch of 1 with the version of the package in the filename. Normally epochs should only be omitted if they are equal to 0, though this is not critical for the filename. In fact there are no strict rules for a package filename, it could literally be anything so long as it is referenced correctly in the repo metadata.
See also: https://www.debian.org/doc/debian-policy/ch-controlfields.html#version

You can verify that the version of the package in question is 1:0.4.5-1build2 by extracting its control file locally yourself:

ar x libxcomposite1_0.4.5-1build2_amd64.deb
zstd --decompress control.tar.zst
tar -xvf control.tar
cat control | grep Version

Does the change in filename (relative to where you got it from) cause any problems for any workflow you use? If so, I would be interested to hear it.

Thanks for the clear issue report. My initial assessment is that this "works as designed".