> > I'm not so excited about programs shelling out to sq. Although we plan to
> > have a stable API in a few months, we still don't have machine-readable
> > output. (We plan to implement that in 2025.) I'd rather we specify an API,
> > and then I implement it in rpm-sequoia (or some another library?).
>
> API in rpm-sequoia would be by far preferred by me too, and something I
> thought would eventually happen anyhow, this was more based on "what tools do
> we have right now". The shell-out part I envisioned would be basically for
> import and delete, where the only thing we care is exit code from the call,
> not looking at any of the output. Just reading the bits off disk shouldn't be
> too complicated for rpm to implement by itself. The overall picture wasn't
> probably too clear in the initial description, sorry about that.
>
I would rather avoid this, because we will wind up in a situation where things
parse the output as API. This happened in DNF with rpmkeys and it happens all
the time in Zypper too.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3341#issuecomment-2382985377
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/3341/2382985...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
