[arch-projects] [dbscripts] [PATCH] Do not support wildcards in PKGEXT, and standardize on xz compression.
This results in unpredictable behavior when used across, variously, bash [[, POSIX sh [, and find -name Its usage depended on matching only one result, which is bad practice. Moreover, it never worked in the first place as - The majority of alternative compression extensions available in makepkg do not use *exactly* two chars. - It accepted lots of extensions that aren't valid at all, like for example .pkg.tar.💩z (which is what I think of using nonstandard compression schemes). Since devtools pushes xz, and every single package currently in the repos uses xz, and AFAIK we haven't actually used any others, it makes sense to just assume xz as the only supported PKGEXT. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> --- config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config b/config index d2c1942..d292c9f 100644 --- a/config +++ b/config @@ -25,7 +25,7 @@ TMPDIR="/var/tmp" ARCHES=(x86_64) DBEXT=".db.tar.gz" FILESEXT=".files.tar.gz" -PKGEXT=".pkg.tar.?z" +PKGEXT=".pkg.tar.xz" SRCEXT=".src.tar.gz" # Allowed licenses: get sourceballs only for licenses in this array -- 2.16.1
On Thu, 15 Feb 2018 17:53:08 -0500, Eli Schwartz via arch-projects wrote:
Since devtools pushes xz, and every single package currently in the repos uses xz,
FWIW, devtool's lib/common.sh's find_cached_package() uses the glob ".pkg.tar?(.?z)".
and AFAIK we haven't actually used any others, it makes sense to just assume xz as the only supported PKGEXT.
IIRC, .gz was used for some packages until around ~2011. Until 2011-03-26 the glob was ".pkg.tar.*", but in 575ba47 it was changed to the current ".pkg.tar.?z" as part of supporting package signing (so that it wouldn't match the .pkg.tar.*.sig files). If my recollection of having .gz files is correct, that change makes a bit of pragmatic sense; .gz and .xz were the extensions in use when that change was made. As for continuing to support globs: that's functionality that will be needed if the prescribed PKGEXT ever changes. It isn't enough to simply change dbscripts' PKGEXT to the new one; for some time after that, it will need to be able to find packages with the old extension (imagine if ftpdir-cleanup stopped seeing the old extension!) IDK if you guys think it's worth keeping the the globbing code around just for the eventuality that a new compression scheme comes around. If not, I'm fine with this change. -- Happy hacking, ~ Luke Shumaker
participants (2)
-
Eli Schwartz
-
Luke Shumaker