xbps-rindex: remove mode

[Chocimier]

[Duncaen]

I don't see how this solves the problem. Removing packages from the index is not the problem of https://github.com/void-linux/void-packages/pull/9745. The problem is removing packages from the users installation.

[Chocimier]

Removing current installations is already solved there. This together with https://github.com/void-linux/void-packages/pull/10791 prevents new installs of empty packages, and also listing in xbps-query -R, https://voidlinux.org/packages etc.

[Duncaen]

I don't think its solved; it is a work around for something which would be better solved by xbps itself.

What I don't like about this proposed change in particular is, that it depends on a intermediate state of templates. This feels like something that is designed to just work with how current CI/build servers work.

I'd rather have xbps-checkvers output deleted packages and then have xbps-bulk or the future build server replacement handle this than xbps-src with pseudo bumps and a temporary keyword.

I guess I could accept a -R flag, which xbps-bulk and future build servers can use, but there are a few points:

• It should work like the add method (get the repository from the path to the package file).
• Simplify the unindex logic, I think you wouldn't need to compare versions and check reverts anymore.
• But one big problem, which breaks the whole -R concept are noarch packages and how the current xbps-clean-repos script/cronjob works. The cleanup script explicitly adds all $arch and noarch packages to the repository before running xbps-rindex -r repo. I'm currently not sure why it does it for $arch packages, but for noarch packages this is necessary to have all the different indexes have the same (latest) version of a noarch package in the index, otherwise the wrong noarch package gets unlinked.

[Chocimier]

I'd rather have xbps-checkvers output deleted packages and then have xbps-bulk or the future build server replacement handle this than xbps-src with pseudo bumps and a temporary keyword.

You convinced me, this feels better and solves point of @jnbr from https://github.com/void-linux/void-packages/pull/10791.

for noarch packages this is necessary to have all the different indexes have the same (latest) version of a noarch package in the index, otherwise the wrong noarch package gets unlinked.

Removing binpkgs shared between indexes based on information from one index is a bad idea by itself. Can the logic be changed to listing binpkgs registered in each index, joining this list, then removing ones not needed by any? - Yes, that will not use xbps-rindex -r in its current form.

[Duncaen]

I always wanted xbps-rindex to open all repositories and to make i.e. the staging code aware of relations between different repositories, which currently still results in problems that the staging is solving for one repository.

I'm not sure what other problems this would introduce as it would have to lock all the repositories and then multiple builders might race when one of the builders is currently adding things. Another idea was to keep xbps-rindex as it is and keep the xbps-src operations as simple as possible, but add something like xbps-repoadmin which would be a tool to merge and publish public repos, so instead of doing staging etc in the xbps-src → xbps-rindex xbps-repoadmin would selectively add things from the unpublished xbps-src repositories to public repositories.

I have to think more about this, xbps-rindex definitively needs to be improved.

[pullmoll]

To avoid races between multiple builders trying to lock multiple *-repodata or *-stagedata files another global lock file like all-repodata.lock could solve this. It would be required only for the case(s) where more than the per arch repository is needed, e.g. when force adding a *.noarch.xbps to synchronize other architectures which also reference it.

[Chocimier]

There is also Dijkstra's solution of ordering repodatas (say, alphabetically by path), then locking in that order and unlocking in opposite order.

[pullmoll]

Ordering and trying to lock seems more complicated to me, though. Of course xbps-rindex could always look for a all-repodata.lock and, even when not trying to acquire it, still wait for it to be released before trying to lock its own repodata.

[Chocimier]

one big problem, which breaks the whole -R concept [...] cleanup script explicitly adds all $arch and noarch packages

This can be solved without xbps-repoadmin, by builbot removing and unregistering packages. List of packages will come from xbps-checkvers passed by xbps-bulk, as Duncaen proposed.

Will it be ok?

[Chocimier]

• It should work like the add method (get the repository from the path to the package file).
• Simplify the unindex logic, I think you wouldn't need to compare versions and check reverts anymore.

Done

[Duncaen]

This would help a lot with quickly clean specific packages from the repositories while xbps-rindex is not aware of all repositories so we don't have to do the registering noarch stuff.

:+1:

[Chocimier]

Rebased.