Parsing a spec, even unsuccessfully, will affect the global macro
state in any number of ways that may affect the following operations
in unpredictable ways. Lacking any saner way to do this, reset the
entire global macro state after each spec parse in rpmspec and spec
query code (rpmbuild already does this) while maintaining possible
cli-specified target and rcfile.
LGTM flags localtime() as a "dangerous" function, which seems a bit
over the top to me, but as we're flirting with threads, it certainly
is not thread-safe.
RPMDBI_PACKAGES differs from the indexes in how record searches behave,
indexes return NULL for non-existent values but with RPMDBI_PACKAGES
(and the pseudo index LABEL) we always get an iterator which we need to
walk to determine whether there's data or not. Use the newly introduced
helper to get the query return right.
One could argue that this should be done in the database code, but then
the behavior is kinda consistent other iteration over RPMDBI_PACKAGES:
you don't know how many, if any, matches there are until you walk it.
With usernames >= 8 characters long, the username and groupname are
printed together creating an unintelligible mess. Ensure space between
user and group.
What a sorry little bug, and easily 15+ years old.
These are common in all cli operation, hiding them in "query flags" under
yet another (or actually two, QUERY_DIGEST / VERIFY_DIGEST etc) different
names and then translating back to internal vsflags everywhere doesn't
make anybody's life easier. No functional changes from cli point of view,
any theoretical API users will need changes of course.
This makes the whole thing simpler and conceptually clearer as these
are not really different query targets, only filters by inclusion.
No functional changes intended from rpm cli perspective, API and
ABI are of course broken here.
No functional changes, just an API break in the practically unused
cli-department. Of course wouldn't be worth the breaking unless there
was a benefit, which will come in later commits.
This can be used to differentiate files that are not natural parts of
packages but created as by-products of our processing so they're easy
to filter out of queries.
Possible candidates include build-ids, byte compiled files etc, but this
nothing is automatically marked as artifact in this commit.
rpmdbCheckSignals() is a public function and it'd be trivial to keep
it but there are no known callers and its such a hysterical name that
lets just get rid of it while we're breaking the ABI anyway...
We only have a disabler for %ghost files ATM but that doesn't mean
the actual code can't be generic, the logic is actually much clearer
this way (especially compared to the to-negate-or-not-to-negate
fun on verify side)
One might envision a generic way to set filters via a cli argument to
go with this, eg --noattr=cd to skip documentation and configs,
or --noattr=g as an alias to --noghost.
This is too flimsy a mechanism for such a critical item as signature
checking: with the innocent- and unrelated looking commit
e3e5db7f39 in place,
'rpm -q foo.rpm' runs with NO signature checking whereas 'rpm -qp foo.rpm'
does signature check. Not sane behavior.
Also the commit is buggy to begin with, qva->qva_source is not a bitfield
so most queries would run with signature checking enabled still.
Revisit some day in a different form, maybe.
This reverts commit b30fca9eed.
When --builtrpms is used then rpmspec operates only on the binary
package headers of packages which would be built from spec. That means
ignoring package headers of packages that won't be built from spec
i. e. ignoring package headers of packages without file section.
If it is defined then it is used for queries when "-p" is not set on
commandline. If it is not defined then macro _vsflags_query is used.
For queries with "-p" on commadline macro _vsflags_query is always used.
Macro _vsflags_query_rpmdb is set to 0xf0f00 (no checking) by default.
(rhbz:#438625)
- This makes "now" be "now" on "package query started" than
"some arbitrary point in process lifetime when", which could
in theory be arbitrarily long in the past. Which should be
a sane thing... and also avoids having to do pthread tricks
for such a silly and cheap-to-call thing.
- This changes query behavior quite a bit as files with non-installed
status are no longer returned as matches. The rationale is that
it makes figuring out dependency issues with the "new" behavior
more obvious (but perhaps we should have a switch to enable
former behavior). Besides not satisfying dependencies, files with
non-installed status are not really owned by the package, as they
would not be removed on package removal.
- RPMQV_WHATPROVIDES only falls through to RPMQV_PATH on absolute
paths, so the only place checking for provides_checked value would
never be reached in the case it was set.
- Add a comment about the fallthrough case
- The common pattern here is grabbing current flags to a local
variable, modifying them for an operation and then restoring,
which is fine... but we dont care about the previous flags
when we're restoring them.
- Finding out which package provides a file with a given digest
is just .. useless functionality. Being next to useless is one
thing, but we pay a high price for this particular uselessness:
the index needed for this is one of the biggest and most expensive
indexes we have.
- Handle source rpm query as a new query source type RPMQV_SPECSRPM,
rename the binary query to RPMQV_SPECRPMS, with RPMQV_SPECFILE
as a backwards compatibility alias to RPMQV_SPECRPMS.
- Turn applyFilters() into match iterator initializer which optionally
applies filters if present
- Handle NULL iterator error codes centrally in rpmcliShowMatches()
- Instead of masking and bitfiddling all over the place, use the
new getters to get the exact (enum) type directly. rpmTagGetType()
is now unused within rpm but leaving around for backwards compatibility
- Eliminates quite a bunch of redundant error code return hoop-jumping
and makes the iterator init + frees nicely paired all together
inside rpmcliArgIter().
- RPMQV_ALL and RPMQV_RPM do nothing but call rpmcli/giShowMatches()
in rpmQueryVerify(), call them directly from rpmcliArgIter() instead
- Make iterator allocation + deallocation symmetric: both
rpmcliArgIter() and rpmQueryVerify() now free what they alloced,
rpmfooShowMatches() is a weird place for freeing
- This is an inconsistent oddball interface which only works for
limited query types, "cli" level API users are better off calling
rpmcliQuery() / rpmcliArgIter() instead
- Technically this changes the rpmcliQuery() and rpmcliVerify() API
in the sense that we no longer honor the qva->qva_flags for the
--nosignature and others, but we assume anybody using these (as if
anybody was using the "cli" API) uses rpmcliInit() which takes
care of these common bits... shrug.
- Ditch ancient and hidden --nopgp --nogpg switches along with the
dishwater which are simply alias to --nosignature.
- Eliminate now unused qva_flags from rpmInstallArguments (along with
a double vsflags goo from rpmgraph)
Panu Matilainen