keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
80dc572514
rpm-ostree/Makefile-libpriv.am

71 lines
2.6 KiB
Plaintext
Raw Normal View History

Link lib/ against libpriv/, use it to share sack loading function On the plus side, we share some code between the library and the binary now. On the downside, because `librpmostreepriv.la` is a noinst library, its code text is duplicated between the shared library and binary, at least until we either: - Have the binary solely use the public shared library (like ostree does) - Install `librpmostreepriv.so` to e.g. `/usr/lib64/rpm-ostree/librpmostreepriv.so` without the headers being public
2015-04-17 21:03:24 +03:00
# Copyright (C) 2015 Colin Walters <walters@verbum.org>
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2 of the License, or (at your option) any later version.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with this library; if not, write to the
# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
buildsys: Unify build of binary and internal shared library This completes the task of unifying the build of all of our C/C++ into a single unit, which avoids code duplication and will allow us to more easily use LTO in the future.
2020-12-17 01:04:40 +03:00
librpmostreepriv_sources = \
Port rpmostree-postprocess to C++ Prep for using https://cxx.rs/
2020-12-06 22:46:20 +03:00
src/libpriv/rpmostree-postprocess.cxx \
Link lib/ against libpriv/, use it to share sack loading function On the plus side, we share some code between the library and the binary now. On the downside, because `librpmostreepriv.la` is a noinst library, its code text is duplicated between the shared library and binary, at least until we either: - Have the binary solely use the public shared library (like ostree does) - Install `librpmostreepriv.so` to e.g. `/usr/lib64/rpm-ostree/librpmostreepriv.so` without the headers being public
2015-04-17 21:03:24 +03:00
src/libpriv/rpmostree-postprocess.h \
Port rpmostree-json-parsing to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/libpriv/rpmostree-json-parsing.cxx \
Link lib/ against libpriv/, use it to share sack loading function On the plus side, we share some code between the library and the binary now. On the downside, because `librpmostreepriv.la` is a noinst library, its code text is duplicated between the shared library and binary, at least until we either: - Have the binary solely use the public shared library (like ostree does) - Install `librpmostreepriv.so` to e.g. `/usr/lib64/rpm-ostree/librpmostreepriv.so` without the headers being public
2015-04-17 21:03:24 +03:00
src/libpriv/rpmostree-json-parsing.h \
Port rpmostree-util to C++ Prep for using https://cxx.rs/
2020-12-19 19:12:39 +03:00
src/libpriv/rpmostree-util.cxx \
Link lib/ against libpriv/, use it to share sack loading function On the plus side, we share some code between the library and the binary now. On the downside, because `librpmostreepriv.la` is a noinst library, its code text is duplicated between the shared library and binary, at least until we either: - Have the binary solely use the public shared library (like ostree does) - Install `librpmostreepriv.so` to e.g. `/usr/lib64/rpm-ostree/librpmostreepriv.so` without the headers being public
2015-04-17 21:03:24 +03:00
src/libpriv/rpmostree-util.h \
libpriv: add new rpmostree-types.h There are types that we want to share between the daemon and the client for deduplication. Those are, as expected, related to D-Bus things like formats and enums. Let's create a new file for it rather than shove it in `rpmostree-util.h`. As mentioned in the file, some of these probably belong better directly in the public API. Closes: #1147 Approved by: cgwalters
2018-01-22 19:44:16 +03:00
src/libpriv/rpmostree-types.h \
Port rpmostree-passwd-util to C++ Prep for using https://cxx.rs/
2020-12-19 00:49:43 +03:00
src/libpriv/rpmostree-passwd-util.cxx \
Link lib/ against libpriv/, use it to share sack loading function On the plus side, we share some code between the library and the binary now. On the downside, because `librpmostreepriv.la` is a noinst library, its code text is duplicated between the shared library and binary, at least until we either: - Have the binary solely use the public shared library (like ostree does) - Install `librpmostreepriv.so` to e.g. `/usr/lib64/rpm-ostree/librpmostreepriv.so` without the headers being public
2015-04-17 21:03:24 +03:00
src/libpriv/rpmostree-passwd-util.h \
libpriv: Add RpmOstreeRefTs and API to create one from a commit This API is intended for use by the caching framework to hold open an rpmdb for the previous commit.
2015-05-22 17:54:41 +03:00
src/libpriv/rpmostree-refts.h \
Port rpmostree-refts to C++ Prep for using https://cxx.rs/
2020-12-19 21:17:03 +03:00
src/libpriv/rpmostree-refts.cxx \
Port rpmostree-core to C++ More prep for using https://cxx.rs/
2020-12-06 23:54:37 +03:00
src/libpriv/rpmostree-core.cxx \
Rename rpmostree-hif.[ch] -> core This is really going to be the heart of rpm-ostree, so let's give it a better name.
2016-02-09 18:38:38 +03:00
src/libpriv/rpmostree-core.h \
core: Split out a -private.h header with struct Prep for doing the "single object, multiple .c files" pattern like is done in e.g. libostree with OstreeRepo and `ostree-repo-{refs,commit.c}` etc. For jigdo we'll need to split things up (see what I did there?). Closes: #1168 Approved by: jlebon
2017-12-21 14:29:30 +03:00
src/libpriv/rpmostree-core-private.h \
Convert some code to compile in C++ mode This is part of investigating using https://cxx.rs/ In order to make this really work, we need to convert some of our C code to C++ so we can include cxx.rs-generated code. This starts by converting just two files as a starting point. I did the minimal porting; I didn't try to actually rewrite them to resemble modern C++, just "C in C++ mode".
2020-11-22 22:55:06 +03:00
src/libpriv/rpmostree-bwrap.cxx \
lib: Extract bwrap-executing internal API The treecompose code will learn how to use bwrap instead of libcontainer in libglnx, since the latter is a buggy copy of a subset of the former. Closes: #429 Approved by: jlebon
2016-08-12 20:03:23 +03:00
src/libpriv/rpmostree-bwrap.h \
Port rpmostree-kernel to C++ Prep for reworking `core.rs` to use cxx-rs (Notable in this is the dropping of `goto out` by writing a small struct with a destructor to handle the cleanup `unlinkat()` for us)
2020-12-11 04:36:49 +03:00
src/libpriv/rpmostree-kernel.cxx \
libpriv: Introduce an rpmostree-kernel.[ch] for dracut Since the dracut run is now separated from the rest of postprocess, we change it to use the bwrap API diretly, and this lets use the new _IMMUTABLE bwrap type. This will make it easier to reuse for client-side initramfs regeneration. Splitting this off makes it also easier to simplify the remaining mutable usage in postprocess.c. Closes: #560 Approved by: jlebon
2017-01-06 06:55:11 +03:00
src/libpriv/rpmostree-kernel.h \
Port rpmostree-origin to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/libpriv/rpmostree-origin.cxx \
daemon: Introduce an origin structure In prep for adding "regenerates initramfs" to "is locally assembled", we need more abstraction. I previously introduced a helper function, but I'd still need to touch every call site when changing that. Rather than having each caller re-parse the origin, let's parse it once into a structure, and then have error-free accessors for it (that also don't malloc). This way when adding a new flag, I don't need to touch every call site. Notes: - Some places in the code (like the deployments -> variant bits) tried to handle deployments without an origin gracefully. That's no longer true. I'm not sure how much we care - do we? - There are a few places where I changed `packagelist.len() > 0` to `is_locally_assembled()`. I think this is right, but we'll need to be sure the "no packages to overlay, just initramfs" case works when that lands. Closes: #566 Approved by: jlebon
2017-01-11 22:05:18 +03:00
src/libpriv/rpmostree-origin.h \
Port rpmostree-scripts to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/libpriv/rpmostree-scripts.cxx \
core: Initial implementation of %posttrans using bwrap+rofiles-fuse In order to make many things work, we need to run scripts. Short version: For now, we: - Run `%posttrans` - Treat most `%post` as the same as `%posttrans` - Ignore `%preun` and such since we never uninstall Most importantly though, we start to build up an "override" list for script handling. Currently it's just a blacklist of scripts we don't need. Significant work here would be needed to run Lua scripts, so far I've been able to just skip them. Closes: #338 Approved by: jlebon
2016-06-17 22:14:24 +03:00
src/libpriv/rpmostree-scripts.h \
(cleanup): Move the refsack and root loading code into libpriv We had `src/lib` having its own little private library; I wanted to use some of it inside `src/libpriv`, so let's consistently have all private utility code in `src/libpriv`. Closes: https://github.com/projectatomic/rpm-ostree/pull/147
2015-05-20 20:21:48 +03:00
src/libpriv/rpmostree-refsack.h \
Convert some code to compile in C++ mode This is part of investigating using https://cxx.rs/ In order to make this really work, we need to convert some of our C code to C++ so we can include cxx.rs-generated code. This starts by converting just two files as a starting point. I did the minimal porting; I didn't try to actually rewrite them to resemble modern C++, just "C in C++ mode".
2020-11-22 22:55:06 +03:00
src/libpriv/rpmostree-refsack.cxx \
More C++ porting, round 6 Port rojig-build and rpm-util to C++. Prep for using https://cxx.rs/
2020-12-19 18:29:13 +03:00
src/libpriv/rpmostree-rpm-util.cxx \
Link lib/ against libpriv/, use it to share sack loading function On the plus side, we share some code between the library and the binary now. On the downside, because `librpmostreepriv.la` is a noinst library, its code text is duplicated between the shared library and binary, at least until we either: - Have the binary solely use the public shared library (like ostree does) - Install `librpmostreepriv.so` to e.g. `/usr/lib64/rpm-ostree/librpmostreepriv.so` without the headers being public
2015-04-17 21:03:24 +03:00
src/libpriv/rpmostree-rpm-util.h \
Port rpmostree-importer to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/libpriv/rpmostree-importer.cxx \
libpriv: Rename "unpacker" to "importer", split off "unpacker-core" In the jigdo path we don't actually want to import the OIRPM literally into ostree. I considered adding jigdo logic into `rpmostree-unpacker.c` but it'd be a mess as the functionality is quite logically separate from importing. So split off an `unpacker-core.c` file which has the bare libarchive+RPM helpers, and rename `RpmOstreeUnpacker` to `RpmOstreeImporter`. Closes: #1110 Approved by: jlebon
2017-11-18 00:57:05 +03:00
src/libpriv/rpmostree-importer.h \
Port rpmostree-unpacker-core to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/libpriv/rpmostree-unpacker-core.cxx \
libpriv: Rename "unpacker" to "importer", split off "unpacker-core" In the jigdo path we don't actually want to import the OIRPM literally into ostree. I considered adding jigdo logic into `rpmostree-unpacker.c` but it'd be a mess as the functionality is quite logically separate from importing. So split off an `unpacker-core.c` file which has the bare libarchive+RPM helpers, and rename `RpmOstreeUnpacker` to `RpmOstreeImporter`. Closes: #1110 Approved by: jlebon
2017-11-18 00:57:05 +03:00
src/libpriv/rpmostree-unpacker-core.h \
Port rpmostree-output to C++ Prep for using https://cxx.rs/
2020-12-18 21:17:11 +03:00
src/libpriv/rpmostree-output.cxx \
daemon: add TaskBegin, TaskEnd, and PercentProgress Closes: #260 Approved by: cgwalters
2016-05-10 19:17:26 +03:00
src/libpriv/rpmostree-output.h \
Port rpmostree-editor to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/libpriv/rpmostree-editor.cxx \
app/libpriv: add editor option for karg command Add editor option for kernel arguments. The logic was taken from the ostree-commit editor. The user now can edit the kernel arguments from an editor. The synchronization related issue is resolved by reloading the sysroot and see if the sysroot has been changed since the call of the editor prompt. Closes: #1097 Approved by: jlebon
2017-11-02 23:24:37 +03:00
src/libpriv/rpmostree-editor.h \
status: Import systemd bits to use UTF-8 circle It's slightly prettier, but this is just laying some groundwork/precedent for importing more systemd code and using it for our formatting. Closes: #295 Approved by: jlebon
2016-05-29 21:15:29 +03:00
src/libpriv/libsd-locale-util.c \
src/libpriv/libsd-locale-util.h \
Initial support for automatic updates This patch introduces a new `AutomaticUpdatePolicy` configuration. This was a long time coming for rpm-ostree, given that its update model makes it extremely apt for such a feature. The config supports a `check` mode, which should be very useful to Atomic Workstation users, as well as a `reboot` mode, which could be used in its present form in simple single node Atomic Host situations. There is still a lot of work to be done, including integrating advisories, and supporting a `deploy` mode. This feature hopefully will be leveraged as well by higher-level projects like GNOME Software and Cockpit. Closes: #1147 Approved by: cgwalters
2017-12-15 20:01:46 +03:00
src/libpriv/libsd-time-util.c \
src/libpriv/libsd-time-util.h \
Port rpmostree-libarchive-input-stream to C++ Prep for using https://cxx.rs/
2020-12-19 21:17:03 +03:00
src/libpriv/rpmostree-libarchive-input-stream.cxx \
Introduce experimental "rpm-ostree jigdo" Tracking issue: https://github.com/projectatomic/rpm-ostree/issues/1081 To briefly recap: Let's experiment with doing ostree-in-RPM, basically the "compose" process injects additional data (SELinux labels for example) in an "ostree image" RPM, like `fedora-atomic-host-27.8-1.x86_64.rpm`. That "ostree image" RPM will contain the OSTree commit+metadata, and tell us what RPMs we need need to download. For updates, like `yum update` we only download changed RPMs, plus the new "oirpm". But SELinux labeling, depsolving, etc. are still done server side, and we still have a reliable OSTree commit checksum. This is a lot like [Jigdo](http://atterer.org/jigdo/) Here we fully demonstrate the concept working end-to-end; we use the "traditional" `compose tree` to commit a bunch of RPMs to an OSTree repo, which has a checksum, version etc. Then the new `ex commit2jigdo` generates the "oirpm". This is the "server side" operation. Next simulating the client side, `jigdo2commit` takes the OIRPM and uses it and downloads the "jigdo set" RPMs, fully regenerating *bit for bit* the final OSTree commit. If you want to play with this, I'd take a look at the `test-jigdo.sh`; from there you can find other useful bits like the example `fedora-atomic-host.spec` file (though the canonical copy of this will likely land in the [fedora-atomic](http://pagure.io/fedora-atomic) manifest git repo. Closes: #1103 Approved by: jlebon
2017-11-09 22:54:33 +03:00
src/libpriv/rpmostree-libarchive-input-stream.h \
daemon: add TaskBegin, TaskEnd, and PercentProgress Closes: #260 Approved by: cgwalters
2016-05-10 19:17:26 +03:00
$(NULL)
Add --enable-rojig, disable by default We're seeing some CI failures that I think are a bug in rojig. In the bigger picture...we never actually started using this, and I think longer term shipping os updates via containers probably makes more sense. I put a *lot* of effort into this code and it's pretty cool so it's hard to just delete it. And *maybe* someone out there is using it (but I doubt it). So rather than just deleting it entirely let's make it a build-time option. I verified that it builds at least.
2020-10-22 20:33:45 +03:00
if BUILDOPT_ROJIG
buildsys: Unify build of binary and internal shared library This completes the task of unifying the build of all of our C/C++ into a single unit, which avoids code duplication and will allow us to more easily use LTO in the future.
2020-12-17 01:04:40 +03:00
librpmostreepriv_sources += \
More C++ porting, round 6 Port rojig-build and rpm-util to C++. Prep for using https://cxx.rs/
2020-12-19 18:29:13 +03:00
src/libpriv/rpmostree-rojig-build.cxx \
Add --enable-rojig, disable by default We're seeing some CI failures that I think are a bug in rojig. In the bigger picture...we never actually started using this, and I think longer term shipping os updates via containers probably makes more sense. I put a *lot* of effort into this code and it's pretty cool so it's hard to just delete it. And *maybe* someone out there is using it (but I doubt it). So rather than just deleting it entirely let's make it a build-time option. I verified that it builds at least.
2020-10-22 20:33:45 +03:00
src/libpriv/rpmostree-rojig-build.h \
Port rpmostree-rojig-assembler to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/libpriv/rpmostree-rojig-assembler.cxx \
Add --enable-rojig, disable by default We're seeing some CI failures that I think are a bug in rojig. In the bigger picture...we never actually started using this, and I think longer term shipping os updates via containers probably makes more sense. I put a *lot* of effort into this code and it's pretty cool so it's hard to just delete it. And *maybe* someone out there is using it (but I doubt it). So rather than just deleting it entirely let's make it a build-time option. I verified that it builds at least.
2020-10-22 20:33:45 +03:00
src/libpriv/rpmostree-rojig-assembler.h \
src/libpriv/rpmostree-rojig-core.h \
Port rpmostree-rojig-client to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/libpriv/rpmostree-rojig-client.cxx \
Add --enable-rojig, disable by default We're seeing some CI failures that I think are a bug in rojig. In the bigger picture...we never actually started using this, and I think longer term shipping os updates via containers probably makes more sense. I put a *lot* of effort into this code and it's pretty cool so it's hard to just delete it. And *maybe* someone out there is using it (but I doubt it). So rather than just deleting it entirely let's make it a build-time option. I verified that it builds at least.
2020-10-22 20:33:45 +03:00
$(NULL)
endif
Reference in New Issue Copy Permalink