Project

Profile

Help

Issue #7756

Content upload has different method-definintion than rpm/file/etc.

Added by mbucher about 1 month ago. Updated 26 days ago.

Status:
NEW
Priority:
Normal
Assignee:
-
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version - Debian:
Platform Release:
Target Release - Debian:
OS:
Triaged:
No
Groomed:
No
Sprint Candidate:
No
Tags:
API Bindings, Katello
Sprint:
Quarter:

Description

Looking at the generated API-Bindings for ruby, the method for creating/uploading a new deb-package differs from the one used for e.g. rpm.

module PulpDebClient
  class ContentPackagesApi
...
    def create(opts = {})

While in the RPM-bindings it looks like this:

module PulpRpmClient
  class ContentPackagesApi
...
    def create(relative_path, opts = {})

The fact that relative_path is specified as parameter in the latter case seems to be due to the fact that in the API, relative_path is marked as required in pulp_rpm, but not in pulp_deb.

https://pulp-deb.readthedocs.io/en/latest/restapi.html#operation/content_deb_packages_create

https://pulp-rpm.readthedocs.io/en/latest/restapi.html#operation/content_rpm_packages_create

THis came up during the katello integration of pulp_deb for pulpcore.

History

#1 Updated by mbucher about 1 month ago

Currently solved this the katello-PR by using a wrapper-method, which should be fine.

If there is a good reason for pulp_deb diverging from how the API works for the other content-types, I am ok with keeping it that way.

Discussion welcome :-)

#2 Updated by quba42 26 days ago

I can provide at least some initial background for this:

pulp_deb currently generates the relative path for packages using various control file fields, to produce the default pool structure that upstream Debian repos use. (Something like pool/<component>/<first_letter_of_package_name_or_lib_plus_fourth_letter_of_package_name>/<package_name>/<file_name>, where <file_name> also follows some default structure).

If I am not mistaken the current implementation runs into trouble if the relative path for a package does not use this default format (requires further testing for details), therefore it is very much "recommended" not to have users provide a relative_path (and rely on the default path generating mechanism instead).

Of course we could consider changing the implementation to permit (more or less) arbitrary relative paths for packages. The question is whether it is worth the effort if there is a simple workaround on the Katello side.

Please register to edit this issue

Also available in: Atom PDF