Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ignore patch level on OpenBSD packages #601

Closed
epsilon-0 opened this issue Mar 26, 2022 · 3 comments
Closed

Ignore patch level on OpenBSD packages #601

epsilon-0 opened this issue Mar 26, 2022 · 3 comments

Comments

@epsilon-0
Copy link
Contributor

epsilon-0 commented Mar 26, 2022

Projects affected
OpenBSD packages in general, with a concrete example of schema2ldif - https://repology.org/project/schema2ldif/versions

OpenBSD packages sometimes have a patch level present in their package version, such as 1.3pl20210902 above, which shows up as problematic in repology. This plXXX should be ignored and treated as just the version by itself.

Observed behavior
plXXX is counted in the patch version and leads to the package marked as problematic.

Expected behavior
Ignore plXXX and unmark the problematic setting.

@AMDmi3
Copy link
Member

AMDmi3 commented Mar 26, 2022

pl is used in openbsd for upstream versions containing patch parts, such as openssh, ntp, lumina, and python:shapely, so we cannot remove it.

@epsilon-0
Copy link
Contributor Author

Oh, OK! Thanks for clarifying.

@AMDmi3
Copy link
Member

AMDmi3 commented Mar 27, 2022

I should probably add that

  • As said, it (mixing up the way of conveying upstream version components and local snapshots) is a problem of openbsd repository
  • We're handling it (IMO) the most graceful way possible - ignoring *pl*, which leads to
    • Snapshots getting ignored status - the least penalizing among the ignored statuses family, and the same as we're using for snapshots in any other repo
    • Upstream p{,atch,post} versions getting ignored (again, the least penalizing) status when coming solely from openbsd, but getting expected status when there's matching p* version from any other repo
  • See [discussion] unified scheme for snapshot versions repology-updater#345 for ideas/discussion on how to handle snapshot versions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants