[aur-dev] [PATCH/RFC 0/5] Use Git repositories to store AUR packages
This patch series adds Git support to the AUR. The scripts are not thoroughly tested and there is no documentation as of now. First comments and reviews are welcome, though! If you want to test this, note that the scripts currently require a patched sshd(8) [1]. I am trying to get this upstream. [1] https://github.com/ScottDuckworth/openssh-akcenv Lukas Fleischer (5): Add support for adding SSH public keys to profiles Add basic Git authentication/authorization scripts Add update hook template Use Git repositories to store packages Add public clone URLs to package details UPGRADING | 10 +- schema/aur-schema.sql | 1 + scripts/git-integration/config.sample | 17 + scripts/git-integration/git-auth.py | 41 + scripts/git-integration/git-serve.py | 106 ++ scripts/git-integration/git-update.py | 334 ++++++ web/html/account.php | 7 +- web/html/pkgsubmit.php | 495 -------- web/lib/Archive/PEAR.php | 1063 ------------------ web/lib/Archive/PEAR5.php | 33 - web/lib/Archive/Tar.php | 1993 --------------------------------- web/lib/acctfuncs.inc.php | 78 +- web/lib/aurjson.class.php | 1 - web/lib/config.inc.php.proto | 4 +- web/lib/pkgbasefuncs.inc.php | 39 - web/lib/pkgbuild-parser.inc.php | 139 --- web/lib/pkgfuncs.inc.php | 195 ---- web/lib/routing.inc.php | 1 - web/template/account_edit_form.php | 5 + web/template/header.php | 1 - web/template/pkg_details.php | 10 +- web/template/pkgbase_details.php | 10 +- 22 files changed, 602 insertions(+), 3981 deletions(-) create mode 100644 scripts/git-integration/config.sample create mode 100755 scripts/git-integration/git-auth.py create mode 100755 scripts/git-integration/git-serve.py create mode 100755 scripts/git-integration/git-update.py delete mode 100644 web/html/pkgsubmit.php delete mode 100644 web/lib/Archive/PEAR.php delete mode 100644 web/lib/Archive/PEAR5.php delete mode 100644 web/lib/Archive/Tar.php delete mode 100644 web/lib/pkgbuild-parser.inc.php -- 2.0.0
Users can now add an SSH public key on the account edit page. This will
later be used to authenticate users via SSH.
Signed-off-by: Lukas Fleischer
This adds two scripts to be used together with Git over SSH:
* git-auth.py is supposed to be used as AuthorizedKeysCommand. It checks
whether the public key belongs to any AUR user and invokes
git-serve.py, passing the name of the corresponding user as a command
line argument, if any.
* git-serve.py is a wrapper around git-shell(1) that checks whether the
user passed as command line argument has access to the Git repository
that a push operation writes to.
Signed-off-by: Lukas Fleischer
This adds a script that can be used as an update hook to check all
commits for validity and to regenerate the package details page before
updating a named ref.
Signed-off-by: Lukas Fleischer
Signed-off-by: Lukas Fleischer
Hi guys, author of Aura (a package manager / AUR helper) here.
Before this got too far along I thought I'd bring up what another AUR
helper dev, my users, and myself have been discussing over the past little
while.
We've been paying close attention to the AUR 3.x development as of late.
Version 2 of the RPC is a godsend, and the upcoming git integration sounds
great. We've discussed the following:
1. RPC V2: It is yet unenforced. It is clearly better to have all
dependency metadata available publicly, rather than rely on shoddy,
insecure Bash parsing/execution done in different ways by every AUR helper,
but the fact remains that the most popular AUR helpers don't enforce AUR 3.
Aura 2 (in development) will, with support for dep resolution of all
non-AUR 3 compliant packages dropped. We believe this is the way forward,
but we face a new problem:
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?
a. Delete every package? Pros: All the long-orphaned packages would be
gone forever. Cons: Current ownership of packages would be lost.
b. Flag every package out-of-date? Pros: Everyone would/should become
aware of the issue, and upload AUR 3 compliant versions of the packages
they maintain. Cons: There's nothing stopping them from just hitting the
"unflag out-of-date" button to circumvent this.
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.
As v2 of the RPC has been released, it would be a waste if its use wasn't
brought to the mainstream. That said, it might be difficult to do so if the
state of the AUR remains as it is.
On 17 June 2014 11:22, Lukas Fleischer
This patch series adds Git support to the AUR. The scripts are not thoroughly tested and there is no documentation as of now. First comments and reviews are welcome, though!
If you want to test this, note that the scripts currently require a patched sshd(8) [1]. I am trying to get this upstream.
[1] https://github.com/ScottDuckworth/openssh-akcenv
Lukas Fleischer (5): Add support for adding SSH public keys to profiles Add basic Git authentication/authorization scripts Add update hook template Use Git repositories to store packages Add public clone URLs to package details
UPGRADING | 10 +- schema/aur-schema.sql | 1 + scripts/git-integration/config.sample | 17 + scripts/git-integration/git-auth.py | 41 + scripts/git-integration/git-serve.py | 106 ++ scripts/git-integration/git-update.py | 334 ++++++ web/html/account.php | 7 +- web/html/pkgsubmit.php | 495 -------- web/lib/Archive/PEAR.php | 1063 ------------------ web/lib/Archive/PEAR5.php | 33 - web/lib/Archive/Tar.php | 1993 --------------------------------- web/lib/acctfuncs.inc.php | 78 +- web/lib/aurjson.class.php | 1 - web/lib/config.inc.php.proto | 4 +- web/lib/pkgbasefuncs.inc.php | 39 - web/lib/pkgbuild-parser.inc.php | 139 --- web/lib/pkgfuncs.inc.php | 195 ---- web/lib/routing.inc.php | 1 - web/template/account_edit_form.php | 5 + web/template/header.php | 1 - web/template/pkg_details.php | 10 +- web/template/pkgbase_details.php | 10 +- 22 files changed, 602 insertions(+), 3981 deletions(-) create mode 100644 scripts/git-integration/config.sample create mode 100755 scripts/git-integration/git-auth.py create mode 100755 scripts/git-integration/git-serve.py create mode 100755 scripts/git-integration/git-update.py delete mode 100644 web/html/pkgsubmit.php delete mode 100644 web/lib/Archive/PEAR.php delete mode 100644 web/lib/Archive/PEAR5.php delete mode 100644 web/lib/Archive/Tar.php delete mode 100644 web/lib/pkgbuild-parser.inc.php
-- 2.0.0
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?
I think that sounds great! We seem to win on all fronts:
- Old packages are given a chance but deleted if proven "dead".
- Everyone is forced to upload an AUR 3+ compliant package.
- There is overlap between the new and old AUR, to give all AUR helpers a
grace period to alter their functionality and handle the new APIs.
On 17 June 2014 14:07, Lukas Fleischer
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?
Am Dienstag, den 17.06.2014, 23:07 +0200 schrieb Lukas Fleischer:
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?
+1 :)
On Tue, Jun 17, 2014 at 11:07 PM, Lukas Fleischer
What do you think of that?
Sounds perfect to me as well :) As Colin stated, I don't see any drawback in this plan.
participants (4)
-
Colin Woodbury
-
Lukas Fleischer
-
Rémy Marquis
-
Stefan Tatschner