The current instructions tell users to perform two actions:
- update the package database
- install the jq package
The only thing users need to or should be doing is actually installing
the jq package -- regardless of which version is being installed.
Guidelines on how to perform system updates are massively out of scope.
In the case of partially performing a system update as a prerequisite
for installing jq, the official guidance from Arch Linux is not to do
this: partial updates are not supported, we refuse to support them, and
anyone who does try to perform them anyway is assumed to know so much
about their system that they clearly do not ever need help from anyone
else (which is a good thing since they won't get it). The result is a
frankensteined system that can only ever be supported by the person who
frankensteined it to begin with. The only reason the package manager
even allows it to occur in the first place is because other
distributions using pacman might have different LTS policies, and
because it would prevent expert users from being in control of their
system, as per the traditional Unix philosophy:
"Unix was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things."
Consequences of performing partial updates without understanding the
ramifications in extensive detail can include breaking the partially
updated application (jq), breaking any application that shares a mutual
dependency with the partially updated application (which jq is *lucky*
to only depend on the ever-backwards-compatible glibc), or breaking the
entire operating system by leaving armed traps behind for the next time
a `pacman -S new-package` is executed and thereby breaks *its* cascading
dependencies.
See:
https://wiki.archlinux.org/index.php/System_maintenance#Partial_upgrades_are_unsupported
The current paragraph is not complete, since a digit is not a special character.
Changing it to:
If the key contains special characters or starts with a digit,
you need to surround it with double quotes like this:
`."foo$"`, or else `.["foo$"]`.
Run `make uninstall` for oniguruma before running the recursive
distclean that will remove oniguruma's Makefile and cause a build error
due to missing make target.
Fetch oniguruma using git submodule instead of a release tarball. It
will fix a build problem, caused by jq's autotools configuration, trying
to run `make distclean` recursively in an empty modules directory. This
will also improve the maintainability of the Dockerfile.
Expressions of the form `path(EXPR) | select(GENERATOR)`, where `EXPR`
is a path expression and `GENERATOR` is a generator conditional
expression (e.g., `has("a"), has("b")`) cause an assertion if the
jq_state VM is torn down too soon. That assert() was only correct if
assuming that the conditional is not a generator.
If the conditional is generator, then what we see is that when
backtracking a SUBEXP_END is executed without a corresponding
SUBEXP_BEGIN because the entire conditional is bracketed with
SUBEXP_BEGIN and SUBEXP_END, and since it's resumed in the middle, in
between the brackets.
Rather than assert that the jq->path_len being restored has some
particular value, we can simply re-compute it from the restored
jq->path.
The behavior of memmem for an empty needle is inconsistent between
implementations of libc.
Our tests imply that we want an empty string needle to be true,
so check for an empty needle before calling memmem.
block_bind_incremental is block_bind_referenced in a loop backwards. For
an 1-inst block, it does the same thing and isn't too much more
expensive, so it's not really useful to keep both.
Also, block_bind_referenced was a better name for the function.
Since 605bfb3, block_drop_unreferenced actually reverses the order of
instructions in the block it's run against. This bug was hidden by the
fact that normally it's run *twice* against the main program, flipping
it back, and that order of function definitionss doesn't really matter
after symbol resolution.
