rpm-ostree/api-doc/rpmostree-sections.txt

<SECTION>
<FILE>librpmostree-core</FILE>
rpm_ostree_get_basearch
rpm_ostree_varsubst_basearch
</SECTION>

<SECTION>
<FILE>librpmostree-dbquery</FILE>
rpm_ostree_db_query
</SECTION>

<SECTION>
<FILE>librpmostree-package</FILE>
RpmOstreePackage
rpm_ostree_package_get_type
rpm_ostree_package_get_name
rpm_ostree_package_get_evr
rpm_ostree_package_get_arch
rpm_ostree_package_get_nevra
rpm_ostree_package_cmp
</SECTION>
lib: Expose new API around basearch For https://pagure.io/atomic-wg/issue/299 we need to make it more convenient to substitute the architecture in an installation context. I plan to use this API inside `rpmostreepayload` in Anaconda, so we can substitute the same value of `${basearch}` we use in treefiles since https://github.com/projectatomic/rpm-ostree/pull/305 Now, you might wonder - why do we need an API wrapping libdnf? It's because libdnf is not API stable yet. We're just exposing a tiny subset. In theory we could use the Python dnf bindings in Anaconda, but things get slightly weird if rpmostreepayload depends on dnf. Perhaps we'll do that down the road, but for now this a small API surface to maintain (forever). This change reworks the internal `varsubst` bits to take a pure `DnfContext`, since we don't want to spin up a whole `RpmOstreeContext` just to do some string substitutions. Closes: #877 Approved by: jlebon 2017-07-13 23:39:01 +03:00			`<SECTION>`
			`<FILE>librpmostree-core</FILE>`
			`rpm_ostree_get_basearch`
			`rpm_ostree_varsubst_basearch`
			`</SECTION>`

doc: Add gtk-doc for new library 2015-04-09 00:20:50 +03:00			`<SECTION>`
			`<FILE>librpmostree-dbquery</FILE>`
			`rpm_ostree_db_query`
			`</SECTION>`
lib: Add RpmOstreePackage The `QueryResult` class ended up being too awkward; having NEVRA strings meant for example that clients would have to parse them. It would be harder to present something like the current `rpm-ostree upgrade` package diff output. Now...I debated quite a while before doing this patch. The thing that's really awful about creating this library is there are SO MANY layers. rpm-ostree → libhif → hawkey → libsolv → librpm. It's enough to make one question whether one is actually accomplishing anything or just contributing to a collective insanity... Let's pretend for now it's the former. Closes: https://github.com/projectatomic/rpm-ostree/pull/136 2015-04-16 05:20:57 +03:00
			`<SECTION>`
			`<FILE>librpmostree-package</FILE>`
			`RpmOstreePackage`
			`rpm_ostree_package_get_type`
			`rpm_ostree_package_get_name`
			`rpm_ostree_package_get_evr`
			`rpm_ostree_package_get_arch`
			`rpm_ostree_package_get_nevra`
lib: Add rpm_ostree_package_cmp() Equivalent to hy_package_cmp(), but works for comparing packages from different memory pools. This a stop gap measure in light of https://github.com/rpm-software-management/hawkey/pull/90 If and when that pull request gets merged, then this function could at some later point simply call hy_package_cmp(). 2015-05-13 17:42:33 +03:00			`rpm_ostree_package_cmp`
lib: Add RpmOstreePackage The `QueryResult` class ended up being too awkward; having NEVRA strings meant for example that clients would have to parse them. It would be harder to present something like the current `rpm-ostree upgrade` package diff output. Now...I debated quite a while before doing this patch. The thing that's really awful about creating this library is there are SO MANY layers. rpm-ostree → libhif → hawkey → libsolv → librpm. It's enough to make one question whether one is actually accomplishing anything or just contributing to a collective insanity... Let's pretend for now it's the former. Closes: https://github.com/projectatomic/rpm-ostree/pull/136 2015-04-16 05:20:57 +03:00			`</SECTION>`