github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-15 20:52:52 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Arch package registry: client error when two versions of a package are present #14114

New Issue
Closed
opened 2025-11-02 11:03:17 -06:00 by GiteaMirror · 5 comments
GiteaMirror commented 2025-11-02 11:03:17 -06:00
Owner
Copy Link

Originally created by @balki on GitHub (Feb 8, 2025).

Description

When a new version of a package is added, the database includes both old and new versions. This confuses pacman client.

error: <repo> database is inconsistent: version mismatch on package <package name>

The default core and extra repos include only the latest version of each package.

Gitea Version

1.23.3

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

archlinux

Database

PostgreSQL

Originally created by @balki on GitHub (Feb 8, 2025). ### Description When a new version of a package is added, the database includes both old and new versions. This confuses pacman client. ``` error: <repo> database is inconsistent: version mismatch on package <package name> ``` The default core and extra repos include only the latest version of each package. ### Gitea Version 1.23.3 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? archlinux ### Database PostgreSQL
GiteaMirror added the topic/packagestype/bug labels 2025-11-02 11:03:18 -06:00
GiteaMirror commented 2025-11-02 11:03:18 -06:00
Author
Owner
Copy Link

@balki commented on GitHub (Feb 8, 2025):

@KN4CK3R Please take a look.

@balki commented on GitHub (Feb 8, 2025): @KN4CK3R Please take a look.
GiteaMirror commented 2025-11-02 11:03:18 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Feb 9, 2025):

Only show the latest version in the Arch index #33262 ?

@wxiaoguang commented on GitHub (Feb 9, 2025): Only show the latest version in the Arch index #33262 ?
GiteaMirror commented 2025-11-02 11:03:19 -06:00
Author
Owner
Copy Link

@ExplodingDragon commented on GitHub (Feb 9, 2025):

Seems like this is an upstream issue with pacman. If there are two different versions of a package in the database, it might trigger this problem. I guess?

Image

@ExplodingDragon commented on GitHub (Feb 9, 2025): Seems like this is an upstream issue with pacman. If there are two different versions of a package in the database, it might trigger this problem. I guess? ![Image](https://github.com/user-attachments/assets/2c211897-35f0-472e-bdd5-d4f32de0655b)
GiteaMirror commented 2025-11-02 11:03:19 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Feb 9, 2025):

Seems like this is an upstream issue with pacman. If there are two different versions of a package in the database, it might trigger this problem. I guess?

Or maybe pacman is just designed that way: it expects the package database should only have one version?

@wxiaoguang commented on GitHub (Feb 9, 2025): > Seems like this is an upstream issue with pacman. If there are two different versions of a package in the database, it might trigger this problem. I guess? Or maybe pacman is just designed that way: it expects the package database should only have one version?
GiteaMirror commented 2025-11-02 11:03:19 -06:00
Author
Owner
Copy Link

@balki commented on GitHub (Feb 9, 2025):

Seems like this is an upstream issue with pacman.

I think it is by design. In each db, only one version of the packages is supposed to be present. libalpm is the official library to work with databases. The function signature below to get a package does not have version parameter. https://man.archlinux.org/man/libalpm_databases.3.en

alpm_pkg_t * alpm_db_get_pkg (alpm_db_t * db, const char * name)

Different versions can be in different databases. E.g. testing can have newest version and core can have current version. But within one database, only one version is expected.

when there is a need to have both older and newer version at the same time, the package name is changed. E.g. postgresql and postgresql-old-upgrade

@balki commented on GitHub (Feb 9, 2025): >Seems like this is an upstream issue with pacman. I think it is by design. In each db, only one version of the packages is supposed to be present. `libalpm` is the official library to work with databases. The function signature below to get a package does not have version parameter. https://man.archlinux.org/man/libalpm_databases.3.en ``` alpm_pkg_t * alpm_db_get_pkg (alpm_db_t * db, const char * name) ``` Different versions can be in different databases. E.g. `testing` can have newest version and `core` can have current version. But within one database, only one version is expected. when there is a need to have both older and newer version at the same time, the package name is changed. E.g. [postgresql](https://archlinux.org/packages/extra/x86_64/postgresql/) and [postgresql-old-upgrade](https://archlinux.org/packages/extra/x86_64/postgresql-old-upgrade/)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label topic/packages type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#14114
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?