There's also an alternative way to buffer all rpmlog() output.
If rust has some reasonable XML support, then data can be exported from a
header into whatever structure you wish rather effortlessly.
E.g. try "rpm -q --xml bash". The --xml is just a queryformat disguised as a
CLI option using a
Overriding qva->qva_showpackage with a short routine that does str =
headerFormat() is what I was recalling having implemented.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Ah my bad: yes, the output is delivered to stout/stderr. And yes rpmcliQuery.
Meanwhile, all the output for each header ends up in a single buffer and a
single fprintf iirc. So it would not be hard to deliver the headerFormat output
for each header through a callback.
Delivery of textual info
> Thanks for the update, but I've been asking NOT to drag in the entire
> lua-compat thing
Right. Which is why I've asked *many* times (including via email and IRC) how
to introduce a new dependency for rpm.
> If you need a place to stick the actually required "~20 lines" of
>
@n3npq where is `rpmQuery` defined? (is it `rpmcliQuery`?)
This is all I could find, and it wasn't immediately obvious how to read results
from it:
http://ftp.rpm.org/api/4.12.0.1/group__rpmcli.html#ga2dbfa3886628a79646b2c286ea5c56d9
--
You are receiving this because you are subscribed to
Again, look at headerFormat() bindings which is kind of like asprintf(3) for
headers and you can then parse the string into whatever rust types you wish
within rust.
I previously suggested you might want to bind the high level rpmQuery() same as
the CLI rpm --query --queryformat ... command to
See lib/rpmtag.h: where the tags are defined. The usual type is appended in the
comment.
There is also rpm -vv --querytags which displays the known tags and types (if
RPM4 doesn't display the types, then an RFE is appropriate)
--
You are receiving this because you are subscribed to this
Garrison "... possibly with count 1". Specifically a RPM_CHAR_TYPE returns a
pointer to data and count is the number of chars in that array. A CHAR scalar
is returned as an array with count 1, ditto for INT* types.
--
You are receiving this because you are subscribed to this thread.
Reply to
@n3npq I am not... definitely good to know as the current code is bogus.
What'd be really helpful in regard to testing tag data is a tag type which
corresponds to each of the tag data types, particularly arrays/vectors of the
integer types.
--
You are receiving this because you are subscribed
(After perusing the td.rs code: perhaps I am misreading some assertions)
Hmmm ... you do realize that only BIN/STRING/I18NSTRING types are scalars?
Specifically, that means that CHAR and INT* types return a pointer to an array
with count items.
Of course BIN is an array of octets, and STRING
@pmatilai using "owned" memory instead of borrowed, in Rust terminology, is an
alternative, and one that could potentially eliminate any possible
use-after-free vulnerabilities.
However, building zero copy APIs on top of things like `HEADERGET_MINMEM` is
something of Rust's raison d'etre, and
I'd really recommend avoiding HEADERGET_MINMEM entirely because of all the
hidden implications, just use HEADERGET_ALLOC always so you can trust the data
isn't going to vanish or move underneath you, like n3npq said you need to
manage unallocation anyway for string arrays.
As for handling tag
This is an identical duplicate of #430, closing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/431#issuecomment-381564764___
Closed #431.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/431#event-1575986977___
Rpm-maint mailing list
Oh, and in case it turns out it's not "~20 lines" but "~2000 lines" (as in: the
full compat-lua thing *is* required in practise): in no case do we want the
compat-lua code imported into rpm git. If the entire compat-lua is required,
the integration should be along the lines of "download latest
Thanks for the update, but I've been asking NOT to drag in the entire
lua-compat thing. If you need a place to stick the actually required "~20
lines" of compat-macros/inline functions, I suppose rpmio/rpmlua.h could be
used for that, it's an internal header anyway.
--
You are receiving this
My largely uneducated take in this is... how about we just forget the exception
clause about specialized environments and just define armv8 in rpm to mean
standard armv8?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
17 matches
Mail list logo
