[pacman-dev] [PATCH 15/15] makepkg: remove unnecessary use of sort(1)
pacman -Qq output is always sorted! $ diff -s <(pacman -Qq) <(pacman -Qq | sort) Files /dev/fd/63 and /dev/fd/62 are identical Signed-off-by: Andres P <aepd87@gmail.com> --- scripts/makepkg.sh.in | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 29b5664..e78bcb1 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1872,7 +1872,7 @@ if (( NODEPS || ( (NOBUILD || REPKG) && !DEP_BIN ) )); then fi elif type -p "${PACMAN%% *}" >/dev/null; then if (( RMDEPS )); then - original_pkglist=($(run_pacman -Qq | sort)) # required by remove_dep + original_pkglist=($(run_pacman -Qq)) # required by remove_dep fi deperr=0 @@ -1883,7 +1883,7 @@ elif type -p "${PACMAN%% *}" >/dev/null; then resolve_deps ${makedepends[@]} || deperr=1 if (( RMDEPS )); then - current_pkglist=($(run_pacman -Qq | sort)) # required by remove_deps + current_pkglist=($(run_pacman -Qq)) # required by remove_deps fi if (( deperr )); then -- 1.7.1
On 19/06/10 09:51, Andres P wrote:
pacman -Qq output is always sorted!
No it is not... it depends on your locale whether the order is correct for inputting into comm. Allan
On Fri, Jun 18, 2010 at 9:37 PM, Allan McRae <allan@archlinux.org> wrote:
On 19/06/10 09:51, Andres P wrote:
pacman -Qq output is always sorted!
No it is not... it depends on your locale whether the order is correct for inputting into comm.
You're wrong, pacman -Qq output *is* always sorted according to LC_COLLATE=C. First I created a package called Kernel26, LC_COLLATE would put it untop since it gives priority to uppercase. en_US does not. $ exec 1>/dev/null $ LC_COLLATE=C comm <(LC_COLLATE=C pacman -Qq) \ <(LC_COLLATE=en_US.UTF-8 pacman -Qq) No errors... but one you use a program that respects LC_COLLATE: $ LC_COLLATE=C comm \ <(LC_COLLATE=C sort <<<$'a\nB\nc') \ <(LC_COLLATE=en_US.UTF-8 sort <<<$'a\nB\nc') comm: file 2 is not in sorted order $ LC_COLLATE=en_US.UTF-8 comm -3 \ <(LC_COLLATE=C sort <<<$'a\nB\nc') \ <(LC_COLLATE=en_US.UTF-8 sort <<<$'a\nB\nc') a comm: file 1 is not in sorted order So the solution is: * Treat the pacman bug as what it is, a separate bug. Since it *does* sort, just to the wrong LC_COLLATE. This is much cleaner than forking sort(1). * Or, simply change comm to LC_COLLATE=C and speed it up since this collation is always faster. Andres P
On 19/06/10 12:54, Andres P wrote:
On Fri, Jun 18, 2010 at 9:37 PM, Allan McRae<allan@archlinux.org> wrote:
On 19/06/10 09:51, Andres P wrote:
pacman -Qq output is always sorted!
No it is not... it depends on your locale whether the order is correct for inputting into comm.
You're wrong, pacman -Qq output *is* always sorted according to LC_COLLATE=C.
First I created a package called Kernel26, LC_COLLATE would put it untop since it gives priority to uppercase. en_US does not.
$ exec 1>/dev/null
$ LC_COLLATE=C comm<(LC_COLLATE=C pacman -Qq) \ <(LC_COLLATE=en_US.UTF-8 pacman -Qq)
No errors... but one you use a program that respects LC_COLLATE:
$ LC_COLLATE=C comm \ <(LC_COLLATE=C sort<<<$'a\nB\nc') \ <(LC_COLLATE=en_US.UTF-8 sort<<<$'a\nB\nc')
comm: file 2 is not in sorted order
$ LC_COLLATE=en_US.UTF-8 comm -3 \ <(LC_COLLATE=C sort<<<$'a\nB\nc') \ <(LC_COLLATE=en_US.UTF-8 sort<<<$'a\nB\nc') a comm: file 1 is not in sorted order
So you are saying that if your locale sorts in a different order that LC_COLLATE=C, then the order output by pacman is wrong for input into comm. Kind of like saying "it depends on your locale whether the order is correct for inputting into comm". Which is exactly what I said and you replied with "you're wrong". Interesting...
So the solution is: * Treat the pacman bug as what it is, a separate bug. Since it *does* sort, just to the wrong LC_COLLATE. This is much cleaner than forking sort(1).
* Or, simply change comm to LC_COLLATE=C and speed it up since this collation is always faster.
Pick one and fix it. Until then the sort stays. If you pick the second, then it would be best to write a bug report about the first. Allan
On Fri, Jun 18, 2010 at 10:48 PM, Allan McRae <allan@archlinux.org> wrote:
So the solution is: * Treat the pacman bug as what it is, a separate bug. Since it *does* sort, just to the wrong LC_COLLATE. This is much cleaner than forking sort(1).
* Or, simply change comm to LC_COLLATE=C and speed it up since this collation is always faster.
Pick one and fix it. Until then the sort stays. If you pick the second, then it would be best to write a bug report about the first.
Allan
If it's one fix at a time, then there's time to think about solutions: There was an old bug in the the archlinux bugtracker involving the combination of LC_COLLATE and some UTF-8 locales in /etc/profile. This would be fixed with `LC_ALL comm`, yet all of makepkg would benefit from a `export LC_COLLATE=C` inline. Since I can't find the bug, I won't use LC_COLLATE yet. And wrt to pacman sorting or not... I was very clear in that pacman always sorts it's output, to which you replied. Andres P
Signed-off-by: Andres P <aepd87@gmail.com> --- $ LC_COLLATE=en_US p -Qsq ernel26$ kernel26 Kernel26 lib/libalpm/package.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/libalpm/package.c b/lib/libalpm/package.c index becbc60..0060300 100644 --- a/lib/libalpm/package.c +++ b/lib/libalpm/package.c @@ -749,7 +749,7 @@ int _alpm_pkg_cmp(const void *p1, const void *p2) { pmpkg_t *pkg1 = (pmpkg_t *)p1; pmpkg_t *pkg2 = (pmpkg_t *)p2; - return(strcmp(pkg1->name, pkg2->name)); + return(strcoll(pkg1->name, pkg2->name)); } /* Test for existence of a package in a alpm_list_t* -- 1.7.1
On 19/06/10 15:55, Andres P wrote:
Signed-off-by: Andres P<aepd87@gmail.com> ---
Please add commit messages. Looking at this patch on its own, I have no idea what the replacement is trying to achieve. I have added a commit message this time. Signed-off-by: Allan
$ LC_COLLATE=en_US p -Qsq ernel26$ kernel26 Kernel26
lib/libalpm/package.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/libalpm/package.c b/lib/libalpm/package.c index becbc60..0060300 100644 --- a/lib/libalpm/package.c +++ b/lib/libalpm/package.c @@ -749,7 +749,7 @@ int _alpm_pkg_cmp(const void *p1, const void *p2) { pmpkg_t *pkg1 = (pmpkg_t *)p1; pmpkg_t *pkg2 = (pmpkg_t *)p2; - return(strcmp(pkg1->name, pkg2->name)); + return(strcoll(pkg1->name, pkg2->name)); }
/* Test for existence of a package in a alpm_list_t*
participants (2)
-
Allan McRae
-
Andres P