On Tue, 17 Jun 2014 at 22:18:54, Colin Woodbury wrote:
[...] 2. The AUR is filled with dead packages. It could use a reboot, rejecting all non-AUR 3 uploads. This would then ensure all packages provide full information via the RPC, and AUR helpers can safely resolve dependencies. The question is, how to reboot? [...] c. Only move non-orphaned packages to the new git-based AUR? Pros: Would clear away the cruft and leave only real packages. Cons: ?
If nothing else, (c.) might give us the greatest hope for a revitalized AUR. The equivalent to (b.) could be accomplished if enough AUR helper users collectively flagged non-AUR 3 compliant packages out of date. [...]
I like that idea. We had the discussion of how to migrate the AUR to Git repositories in another thread and there was no consensus. Let me suggest a slightly modified version of your plan: When AUR 4.0.0 is released, we create an empty Git repository for each package that exists in the AUR at that time. Submitter, maintainer, votes, comments and everything else that is stored in the AUR database is retained, so no one can take over someone else's packages. People can then commit the current version of their PKGBUILD and push into the empty repository. Note that there is a Git hook that checks whether .AURINFO is available before updating the refs on the server. This ensures that source packages without metadata are going to be rejected. People that already used Git repositories for their AUR packages before can rewrite their commits to include metadata and then import the complete history. Git repositories that are still empty after one year will be deleted (including the corresponding packages). The migration will probably start a couple of weeks before the actual release (with a second setup of the new AUR release, while the "old" AUR still runs under the old domain) to avoid a period of time with almost no packages available. What do you think of that?