1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
This is the finalized draft of the project requirements for the
new Arch package submittal process. AUR (Arch User-community Repo).
The sub-directories contain more specific implementation notes
for each component of the project.
Requirements:
-------------
1) User accounts (users, TUs)
- Create account. (email address required)
- Update account (change password/email address)
- Log in/out
2) Search for packages (public)
- needs knowledge of ALL pkgs (OfficalRepos/AUR/Unsupported). This
should be easy enough if this site lives on the same machine as
the current package database (dragon?), or is allowed to query
the db.
- Display official repo (current/extra) a package lives in.
3) Manual voting (requires user acct)
- reset/clear all votes (for starting over, this can be added later
if there is any demand for it)
4) Package Management
- A package can be submitted by anyone (as long as they create
an account with a valid email address on the web site). From
there, a TU inspects the package and works with the submitter
to resolve any bugs/issues. Once approved, the TU can place the
package in the AUR. From there, if the package is popular enough
(or deemed necessary), a developer can move the package from the
AUR to extra/current/etc. A developer can also downgrade a
package from extra/current/etc to the AUR.
- The person that uploaded the new package can make changes to
it before it has been added to the AUR.
- TUs need to be able to purge packages in "Unsupported" if the
package is no longer maintained and there is no interest in
keeping it.
- Packages in the AUR/Unsupported need some sort of 'flag out of
date' support.
- Interested users can download the package from "Unsupported"
and build/install it by hand.
- Provide a separate installation of flyspray for tracking bugs
for packages living in the AUR. All bugs should be resolved
in either flyspray (AUR/official) prior to a package being
promoted/demoted.
5) Reports
- package popularity by number of votes
6) Wiki Docs (UID/GID db, provides db, irc nicks/names TUs/devs)
- Move the appropriate dev wiki pages to the new system's
wiki area. The devs will just need to consult the UID/GID
list from the new system site rather than our own wiki.
7) Submitting 'new' packages by users. Initially start with
a simple web upload page where users submit a tgz containing
the PKGBUILD, scriptlets, patches, etc. The script will
unpack the tgz in an appropriate location and update the
backend database to 'register' the pacakge.
8) TU package management
- A TU adopts a package from "Unsupported" and that shows users
and other TUs that the package is being reviewed.
- When the TU is ready to move the package to the AUR, they
use a custom utility/script that allows them to upload the
pkg.tar.gz (web uploads are inadequate for this process).
The upload utility/script has a server counterpart that
performs TU authentication and updates the database.
- A cronjob on the server can handle the new AUR package,
update the database, and rebuild the AUR sync db, and send
email notices to the TU about errors if any occur.
- The TUs should also be able to demote a package from the
AUR via the web interface.
- TUs will use cvs/svn interface (just like devs) to pull
down the PKGBUILD tree. This tree should reflect the same
layout as extra for easier package migration. They make
changes to their local copy, test, and then commit. They
use the xfer utility to upload the binary package to the
server. No shell access is required.
Automated Voting Tool (similar to ArchStats client)
=====================
Requirements:
-------------
1) Name of tool is 'pkgvote'
2) Requires registered account on web - email address not required
3) Casts 'yes' votes for all installed packages (except itself?)
Implementation:
---------------
A statically compiled C program that gathers the list of installed
packages and casts the vote to the web site. Very similar to the
way that ArchStats works now. When making the HTTP Post, it adds
a custom HEADER that the PHP script(s) can detect to know that it
is receiving a vote from a 'pkgvote' client. If the PHP script
does not see the special HEADER, it assumes it is a web browser
and gives the user HTML output.
Once installed, the user edits the config file and supplies their
username/password. If no username/password exists in the config
file when it starts, it spits out an error message and exits.
|
