#646 prunerepo causes PackageKit errors
Closed 5 years ago by praiskup. Opened 5 years ago by jwakely.

I get frequent problems where PackageKit complains that it's unable to sync the metadata from my COPRs, giving errors like this:

$ pkcon refresh
Refreshing cache              [=========================]
Loading cache                 [=========================]
Downloading repository information[=========================]
Loading cache                 [=========================]
Finished                      [=========================]
Fatal error: Error when getting information for file
“/var/cache/PackageKit/28/metadata/jwakely-gcc-latest/repodata/8621045ed9a345e43f7a552be5ab5298ac4807736795c421fcfc4ce186b764b0-appstream.xml.gz”: No such file or directory

clime looked into it for me and explained it like so:

The problem was caused by automatic prunning (prunerepo), which runs over
all repos, deletes old packages and recreates he repository metadata. The
problem is that it doesn't have support for appstream data so it
regenerates the repo without them. Hence after the next pkcon refresh, the
error appears. Possibly, report the bug at
https://pagure.io/copr/copr/issues as there are more than one way to solve
this. This conversation copied should be enough.


Manually using the "Regenerate Repositories " button on the COPR site seems to solve the problem, so could prunerepo do whatever that does?

Hey, i think--nocreaterepo switch of prunerepo could be used and then all the repodata recreation can be done from the copr_prune_results script so you can recreate the repo exactly in the same manner it is done after each build.

N.B. this creates a potential security issue for people who rely on PackageKit for updating their desktop. When the COPR metadata is missing PK just gives up, and so doesn't let the user install other updates, including any important security updates from the Fedora repos. The only solution for users (who can't regen my COPR metadata) seems to be to disable the COPR.

That's probably a PK bug, as a single bad COPR shouldn't be able to stop the user from getting security updates.

Metadata Update from @praiskup:
- Issue tagged with: bug

5 years ago

Hey, i think--nocreaterepo switch of prunerepo could be used and then all the repodata recreation can be done from the copr_prune_results script so you can recreate the repo exactly in the same manner it is done after each build.

I think, that this is a good idea, better than trying to enhance prunerepo's createrepo possibilities to support appstream, modules and whatever in the future.

Modified in PR#654

Metadata Update from @praiskup:
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata
Related Pull Requests
  • #654 Merged 5 years ago