Ability to use Package filenames when publishing

[daviddavis]

We have a bunch of older deb packages that we need to serve that unfortunately have filenames which don't conform to name-version-architecture.deb. Based on my reading of the publishing code, it looks like it always uses this package filename method (see here and here). Which in turn calls this name method that generates the published package's name with name-version-architecture.deb.

It does look like though that when the package gets added to pulp_deb that it stores the original package filename in relative_path. But I don't see an option/way to actually tell pulp_deb to use relative_path when publishing. So two questions: first is it possible today to somehow use relative_path when publishing and if not, how could we support it (maybe a config variable or a publication create parameter)?

[quba42]

I guess I never replied to this.

I believe you are correct, pulp_deb will always use its own naming scheme for packages in the pool folder published via the APT publisher. I believe it stores the original package name in relative_path for the benefit of verbatim publications.

My question is if this design is really an issue? Even if some package is renamed during publish, so long as the generated metadata is consistent this should not matter to any clients that consume the repo. Or am I missing something?

[daviddavis]

I think the main issue that we ran into is that we migrated (or synced) our packages into Pulp and then pointed our hostname from the old server to Pulp. So we had to use relative_path in order to prevent clients from getting 404s. We have patched pulp_deb so we could continue using the package names (ie relative_path) from the old system to solve this problem of 404s.

We'd like to at some point ditch our fork/patches of pulp_deb (probably after the source package PR is merged and released) but I am guessing if we try to ditch our patch and use pulp_deb's naming scheme (instead of relative_path), clients that have the metadata cached will get 404s?

[daviddavis]

I guess we could test out to see if apt is smart enough to re-fetch the metadata if it receives a 404 when trying to fetch a package that has been renamed.

[quba42]

Based on a recent user experience, I might add that the error message we throw could be more helpful (even if we don't change the design).

The message is currently: "Invalid relative_path provided, filename does not match."
I think something like the following would be more helpful:

"The provided relative_path='{}' does not match the auto generated filename of '{}'. We recommend users simply don\'t provide a relative_path during upload."

Alternatively we could simply drop that API parameter, so it will stop confusing users.