As implemented in commit cdbc7e1d8b,
%{quote:...} only works when its used to quote the entire argument
and produces garbage when used in middle of other text, such as
"x%{quote:y}z". Not sure there's actual need to do that, but producing
garbage is never good.
Only unquoted separators can split an argument, copy argument manually
to strip any quote characters and adjust the math to match. Oh and
add testcases too.
Thanks to Pavlina Moravcova Varekova for pointing this out.
Move color config macro expand into a helper function that's only called
once per thread and use enums for the possible states, ints are nicer
to compare than strings. Also remember to free the expansion result to plug
a memleak as well.
All the nice quote-characters are already spoken for, we need to
do something more special here. Add a special-purpose built-in %{quote:...}
macro which quotes its argument using ASCII unit separator character 0x1f
(so it really shouldn't get into anybodys way) and teach macro argument
splitting to support that.
So with %{quote:...} it's now possible to pass strings containing
whitespace and empty strings as arguments. It might not be pretty, but
it's at least POSSIBLE, and no existing user is bothered by this.
Always require matching number of elements regardless of data type
and number of elements, and error out otherwise. Behaving differently
for plain strings and binaries makes no sense, those checks are ancient
artifacts that have long since ceased to produce what might've been
originally intended behavior.
A remaining quirk is the case where a tag doesn't exist at all, this
produces (none)'s all the way down. Which doesn't seem terribly wrong,
but neither does it seem really consistent with the rest of it. Dunno.
There are some funny quirks here: query 2 case needs to succeed
because there's exactly one changelog entry in the package, but if
that were not the case it should fail (but doesn't, so the testcase
fails for now). So we test for that separately in query 3, and finally
test for %{=foo} (ie repeat first entry) which is required to sort out
different sized arrays in the general case.
Rpm documentation actually states that you must use %{=TAG} for the case
commit 7f47cbbd7d was trying to fix, but
caused regressions in other situations. So the 4.12 behavior is little
more than accidental, rpm is actually supposed to error out here
(but doesn't, which is another bug).
This reverts commits 7f47cbbd7d and
ead9cdd587.
In the cases where zero is a sane return for non-existent data,
return it instead of barfing up an assert. Many more unnecessary
asserts left there but these are rather obvious...
Macro %trace switched on in a nested stage level writes the trace
until the level is leaved to a lower stage level. This did not
work e.g. for macros containing several condition macros.
For example:
%prep
%define Branch1() {%trace %global Leaf1 "1"}
%define Branch2() {%global Leaf2 "2"}
%define Main() {%{?test1: %Branch1} %{?test1: %Branch2}}
%Main
with the result:
4> %global^Leaf1 "1"
2> %{?test1: %Branch2}^
3> %Branch2^
4> %global^Leaf2 "2"
It was because macro expansion is context free. This patch fixes it.
All these years BDB has been relying on undefined behavior by storing
POSIX thread objects in its persistent environment files (for the long
story, see RhBug:1394862). As a side-effect of fixing it in BDB,
all sorts of creatures from dark corners are getting dragged into
the daylight: rawhide glibc gets updated a lot and we're getting
DB_VERSION_MISMATCH hits from rpm queries from package scriptlets
(told you so...), other tools not closing their database handles
when they should etc etc. This lets those cases continue "working"
to the extent they always did (ie unreliably) for now.
We should log some diagnostic message in this case, but coming up
with an understandable and reasonably short message for this mess
isn't that easy :)
Only permit automatic fallback to the essentially lockless operation
of DB_PRIVATE when read-only database is requested. This isn't exactly
correct, as readers need locks for correct operation just like writers do,
but at least in the readonly case the database wont be damaged.
The exception to the rule is systems which don't support the shared mapping
at all so we don't have much choice. Explicitly configured
I-know-what-I'm-doing DB_PRIVATE is not affected either.
Directory name doesn't matter, content does. In specification, both
appdata.xml and metainfo.xml should be in /usr/share/metainfo, but
tools should support /usr/share/appdata as for legacy location.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1483644
Reported-by: Petr Pisar <ppisar@redhat.com>
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Only force RPMLOG_INFO level if running with less verbosity (as is
the case by default), but leave RPMLOG_DEBUG alone. Quiet overrides
any number of -v's though.
Fedora java packages are running into the old limit of sixteen nesting
levels (commit b3179e6de3), bump it up
to 64. The old limit lasted almost twenty years, lets see how far this
gets us.
Oldies but goodies: the max depth is already initialized in declaration
to _MAX_MACRO_DEPTH which has been the same 16 since late nineties. This
wasn't always the case of course...
Send all through rpmlog(), unify formatting - previously echo and
warn were missing the trailing newline. The other change is that
echo now goes to stdout.
v2 (Neal Gompa)
* Switch from RPM_CHECK_LIB to PKG_CHECK_MODULES
* Fix notation of file name in lmdb.c
* Remove MDB_FIXEDMAP flag to prevent portability issues
* Add comment that lmdb is an option for %_db_backend
Closes: #281Fixes: #128
This simply breaks too many things - whole macro ecosystems exist based
on the assumption that quotes in arguments will pass to macros
untouched. Macro argument quoting support is necessary but it'll
need some entirely different approach that is either opt-in or
based on a different syntax altogether.
This reverts commit 47f0a899ef.
The %_debugsource_template expects the debugsourcefiles.list file
to be in the (current) build dir. Make sure that is always the case
even if find-debuginfo.sh was invoked in a different (sub) directory
by adding the build dir path as explicit argument to -S.
Signed-off-by: Mark Wielaard <mark@klomp.org>
Unlike the other rich rependencies they work by evaluating package
sets. This means, "Requires: (foo with bar)" is only fulfilled
by a package that provides both foo and bar. In comparison,
"Requires: (foo and bar)" can be fulfilled by two different
packages.
Without implements set subtraction, e.g. "Requires: (foo without bar)"
is only fulfilled by a package that provides foo but not bar.
This brings rpmdbSortIterator in line with its documentation.
Note that there is a catch: this change also makes the dbiIndexSetPrune
function work different! It used to delete all items that had a
matching hdrNum, after the change only the one is deleted that also
has a matching tagNum. I consider this a bug fix.
Note that dbiIndexSetPrune is only used in the db3.c backend to remove
index entires, if we really want the old behavior we should add a
new dbiIndexSetPruneHdrnum function.
Also remove assertion when trying to sort an empty set.
Panu Matilainen