Back in 2011 "somebody" forgot to apply brain when copying the return
type of "long" from ftell() to the Ftell() implementations within rpmio
(commit 61f5838aa8).
Fast-forward six years and suddenly TexLive in Fedora no longer builds
on 32bit architectures due to that thinko, appearing to be a regression
in commit 7d1a303c45. However that only
exposes the inner flaw of Ftell() as the code now relies on values
past the initial header range, for which the 2G of "long" has been more
than enough on 32bit architectures too.
Doh, dude...
Directory names as stored in RPMTAG_DIRNAMES are not sorted when
separated from basenames, so binary search has no chance of working.
While a linear search on the dirnames would be guaranteed to find *some*
matches when they exist, it could still miss some results as the
matches are not guaranteed to exist in a neat low-high range.
Construct the entire pathname for prefix comparisons to ensure sorted
paths and adjust the file trigger testcase to cover this too.
Thanks to Pascal Terjan for initial investigations and Thierry
Vignaud for providing a workable reproducer.
In the distant past when rpm just stat()'ed all mounted filesystems,
it was quite necessary to have the option of disabling the fs stats.
However now that we only stat() filesystems we actually use, the
situation is quite the reverse: if stat() eg hangs, we wouldn't be
able to complete the transaction anyway so it's better to find that
out before the transaction even starts, regardless of problem filters.
Also the filesystem info sets could be used to track other things besides
space, such as suid/sgid availability, selinux and file caps support etc.
Non-zero transaction members is not a meaningful test for this, as we can
can fail early for several reasons. Only sync if we actually executed
rpmtsProcess().
If syncfs() is available (ie on Linux), only sync modified filesystems.
In order to do this, keep the diskspace information around throughout
the transaction.
Skip the sync entirely on chroot installations for now, but this
too should be configurable (always/auto/never or so).
There's a bit of a chicken-egg problem with post-transaction plugins:
for example systemd_inhibit should only be released after syncing,
but OTOH some other plugins might be performing actions whose results
should be syncing. Leaving it alone for now.
Prior to this, test-suite PYTHONPATH would be wrong for all but builds
using --prefix equal to system python location, and eg --prefix=/opt
would cause the testsuite to fall back to system rpm bindings instead
of the in-tree one. Ditto for dist-check.
The test-suite fails if python is not enabled. An alternative solution
could be disabling python tests when not enabled, but the python
tests cover things that are not covered elsewhere so especially
for dist cutting the tests are quite important.
distcheck runs from a read-only source tree so the packages that we
copy around for fuzzing "fuzz" have read-only permisssions and
modifications fail, causing the tests to fail. So instead copy the
to-be-modified packages from inside testing/data where the permissions
are taken care of by commit ecb4182655.
Bit hysterical that we haven't done this...
On Linux we could call syncfs() for only those filesystems that we
actually touched but somehow I doubt it's worth the trouble.
Another option might be doing this at rpmtxnEnd() but maybe that's
excessive.
An (A unless B) dependency implements (A and not(B)). This kind is useful
for "or" type dependencies, e.g. "Conflicts" or "Supplements".
As "Conflicts: (A unless B)" is equivalent to "Requires: (B if A)", I
thought this type is not needed. But there is no such equivalence
for Supplements, thus the change in mind.
Like with "if" we also have a syntactic sugar "else" flavor:
(A unless B else C) is the same as ((A unless B) or (B and C))
This commit also makes the "else" handling code in depends.c much
easier to understand.
Simplifies things a bit and also makes "PYTHON=python3 ./configure" work,
whereas it previously barfed on figuring the library names like
"libpython3.6m"
Triggers and file triggers can and do execute scriptlets from installed
packages which are not part of the current transaction and thus have no
associated transaction element, making the scriptlet callbacks
inconsistent and cumbersome for API users.
Create a fake transaction element for the poor orphan scriptlets lacking
one to make it consistent (of course, creating rpmte's with all their
associated data just to pass a header pointer along is ridiculously
expensive but *shrug*).
Regular triggers used to execute in the context of the triggering
transaction element, make them run with the owning trigger header too.
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.
Panu Matilainen