On 24/02, Florian Pritz wrote:

Work on improving dbscripts[1] has resumed and thanks to Gabriel Souza Franco we finally have something[2] that should easily support git packages as well as debug packages, split packages across multiple repos and with different arches. It has lots of new tests, but it could really use a field test and we need to figure out how we want to deploy it once we are satisfied.

Oooh, awesome!

The new dbscripts no longer change the svn repo so the repos subdir is not needed any more. All they require is some form of a tag (like a git tag) to fetch the PKGBUILD. This means we are pretty much free to use whatever we like (including git) as long as we can tag stuff. For the time being we can stick with svn if we like.

Using tags obviously requires that the existing repositories are migrated and that devs/TUs use the new scripts that generate them. This migration is required for the new svn layout and if we switch to git. It is probably a good idea to do both at once so people don't have to update twice, but I'll only do that if we plan this thoroughly.

Currently we treat also extra/core and community separately, but I think there is no real reason for that apart from that we migrated it like that from gerolde. If possible, I'd like to get rid of this distinction.

If this means a single git tag for every package, and for every release of each package, this won't work sanely if we're going to use a single git repo. We'd run into the same problem we had with the AUR where even when we used ref namespaces it will announce /all/ the refs when you try to clone, which ended up causing really slow clones, and even timeouts, when trying to clone any package at all from the AUR.

RFC: As for testing, I'd like some input on my (rather preliminary) migration plan[3] and opinions on whether we want to test it directly on nymeria or somewhere else.

Looks fine to me overall.

[3] https://wiki.archlinux.org/index.php/User:Bluewind/dbscripts-rewrite#Migr= ation_Plan

Florian