[ISV-5094] cachi2 PNC package manager design

[kosciCZ]

Maintainers will complete the following section

• [ ] Commit messages are descriptive enough
• [ ] Code coverage from testing does not decrease and new code is covered
• [ ] Docs updated (if applicable)
• [ ] Docs links in the code are still valid (if docs were updated)

Note: if the contribution is external (not from an organization member), the CI pipeline will not run automatically. After verifying that the CI is safe to run:

• approve GitHub Actions workflows by clicking a button
• approve the Red Hat Trusted App Pipeline container build by commenting /ok-to-test (as is the standard for Pipelines as Code)

[kosciCZ]

@brunoapimentel @chmeliik @eskultety Here's the initial draft of the PNC package manager from KONFLUX-3403, that you've asked for in our last meeting. Please review it and I'll be happy to work in your feedback. Thanks!

cc @allda

[brunoapimentel]

Overall comment: you don't need to follow exactly the structure of the other designs. I think we are mainly separating the design into two distinct parts:

• A quick overview of the package manager/tool/ecosystem to make folks that are not familiar with it up to speed. It can be brief, contain a lot of links to official docs, and only touch the parts that are relevant for Cachi2
• The implementation design by itself.

(we are still considering an "official" format for designs, so this might change a little, but don't worry about it now)

[brunoapimentel]

A suggestion that could aid the design is to implement a PoC. Note that this is not required for the design to be approved, so please only do it if you feel like it would be helpful. I do think that it usually helps to clarify a lot of the design details, and even antecipate some of the issues that can happen.

Here's the PoC created for the Ruby design, and the corresponding test repo we are using alongside with it.

[kosciCZ]

@brunoapimentel thanks for the suggestion. In my opinion, implementing a PoC is an overkill in this case, as the PoC is basically already the work we want to do, so we might as well do it properly the first time around. However, using a test repo is a good idea, even if it should be manual testing during the development (we can figure out the automated integration testing in that thread above)

[kosciCZ]

Closing, as we decided to take a different approach. Will open a new PR for the new design to be reviewed.