We do a lookup by DepName in the package details view, but I made the
silly mistake of forgetting this index addition in the upgrade steps.
Lukas: Fix numbering in "UPGRADING".
Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
We removed the code depending on this a long time ago - drop it and add
some note to "UPGRADING".
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Instead, we just store dependencies directly in the PackageDepends
table. Since we don't use this info anywhere besides the package details
page, there is little value in precalculating what is in the AUR vs.
what is not.
An upgrade path is provided via several SQL statements in the UPGRADING
document. There should be no user-visible change from this, but the DB
schema gets a bit more sane and we no longer have loads of junk packages
in our tables that are never shown to the end user. This should also
help the MySQL query planner in several cases as we no longer have to be
careful to exclude dummy packages on every query.
Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Set it equal to the SubmittedTS field, which will be our indication the
package is new when we show the logo on the front page of the AUR.
This results in the ability to remove the use of the unindexable
GREATEST() function from the AUR code everywhere we had to use it before
to handle the 0 timestamp case.
Note that there is no race condition here in calling UNIX_TIMESTAMP()
twice- it always returns the time at the beginning of statment
execution:
mysql> select unix_timestamp(), sleep(2), unix_timestamp();
+------------------+----------+------------------+
| unix_timestamp() | sleep(2) | unix_timestamp() |
+------------------+----------+------------------+
| 1300851746 | 0 | 1300851746 |
+------------------+----------+------------------+
1 row in set (2.00 sec)
Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Can be used to blacklist package names for normal users. TUs and
developers are not affected. This is especially useful if used together
with a cron job that updates the blacklist periodically, e.g. to reject
packages which are available in the binary repos (FS#12902).
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Drop fulltext indexes, which prevent the use of InnoDB, from "Packages"
table. All search routines use "LIKE" patterns, so fulltext search has
actually never been used.
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
We don't even touch source tarballs anymore - except for extracting the
PKGBUILD, so this is no longer needed.
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
We don't need this anymore since all packages managed here are
well...managed here. Rip out all of the places we were using this field,
many of which depended on the magic value '2' anyway.
On the display side of things, we had a column that was always showing
'unsupported' that is now gone, and you can no longer sort by this column.
Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Automatic tarball extraction was vulnerable in different ways. Users
should also only use source tarballs to build packages, so this has been
removed completely. From now on, only the PKGBUILD is extracted in a
secure manner.
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
