IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
There won't be any support for writing to the bdb backend in f34, so
e.g. pkglayering won't work (and obviously even composes wouldn't work
once the buildroot moves to f34).
Instead of requiring the whole world to add an `rpmdb` key in their
manifests, let's just add a compile flag for it, and tweak the spec file
to use this flag on f34.
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.
A long time ago we de-duplicated the daemon and binary
into a single executable, but left the daemon code
building as an internal static library.
Let's take the next step and compile the sources directly as part
of the executable build. For example, we can then de-duplicate
the `CFLAGS/CXXFLAGS`. And in the future this will help us
turn on LTO.
This is a potential path to fix
https://github.com/coreos/rpm-ostree/issues/2391
Basically our shared library and executable duplicate too much
code (particularly Rust). Since most of the shlib APIs aren't
performance sensitive, let's have them fork off the binary
via a hidden CLI entrypoint and parse the output.
First, we now need the `vendor/` directory at the toplevel because
that's where `Cargo.toml` is.
Now this triggers another bug introduced in the build system
with how we're handling the `rpmostree-rust.h` header.
We ended up vendoring a pre-generated one in the tarball
mainly because RHEL doesn't include cbindgen.
Now probably in the future I'd like to fix that.
But let's clean this up - the tarball generation process copies
the file into `rpmostree-rust-prebuilt.h`, and build machinery
detects that and entirely skips looking for or trying to build
our internal cbindgen.
I think we should have done this as soon as it was clear that
Rust was sticking and not just an optional thing.
Reasons to make this change now:
- More clear that Rust is going to be the majority of code in the future
- `cargo build` and `cargo test` in a fresh git clone Just Work
- Paves the way for using `cargo` to build C/C++ instead of Automake
I still think we should do this at some point, but
the experiment with using `GKeyfile` for configuration
is IMO a failure and the variety of data formats
(treefile JSON vs YAML vs origin keyfiles vs container keyfiles)
causes a lot of confusion.
Prep for https://github.com/coreos/rpm-ostree/issues/2326
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".
This effectively reverts commit: c8113bde32
We never ended up using it; instead the `rdcore` bits from
`coreos-installer` have the rootfs reprovisioning logic.
This command allows users to cheaply inject configuration files in the
initramfs stage without having to regenerate the whole initramfs (or
even a new OSTree commit). This will be useful for configuring services
involved in bringing up the root block device.
```
$ echo 'hello world' > /etc/foobar
$ rpm-ostree ex initramfs-etc --track /etc/foobar
Staging deployment... done
Run "systemctl reboot" to start a reboot
$ rpm-ostree status
State: idle
Deployments:
ostree://fedora:fedora/x86_64/coreos/testing-devel
Version: 32.20200716.dev.1 (2020-07-16T02:47:29Z)
Commit: 9a817d75bef81b955179be6e602d1e6ae350645b6323231a62ba2ee6e5b9644b
GPGSignature: (unsigned)
InitramfsEtc: /etc/foobar
● ostree://fedora:fedora/x86_64/coreos/testing-devel
Version: 32.20200716.dev.1 (2020-07-16T02:47:29Z)
Commit: 9a817d75bef81b955179be6e602d1e6ae350645b6323231a62ba2ee6e5b9644b
GPGSignature: (unsigned)
$ reboot
(boot into rd.break)
sh-5.0# cat /etc/foobar
hello world
```
See the libostree side of this at:
https://github.com/ostreedev/ostree/pull/2155
Lots more discussions in:
https://github.com/coreos/fedora-coreos-tracker/issues/94Closes: #1930
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.
We need to be friendlier to people who are transitioning from
"traditional" yum managed systems. This patchset starts to lay
out the groundwork for supporting "intercepting" binaries that
are in the tree.
For backwards compatibility, this feature is disabled by default,
to enable it, one can add `cliwrap: true` to the manifest.
To start with for example, we wrap `/usr/bin/rpm` and cause it
to drop privileges. This way it can't corrupt anything; we're
not just relying on the read-only bind mount. For example nothing
will accidentally get written to `/var/lib/rpm`.
Now a tricky thing with this one is we *do* want it to write if
we're in an unlocked state.
There are various other examples of binaries we want to intercept,
among them:
- `grubby` -> `rpm-ostree kargs`
- `dracut` -> `rpm-ostree initramfs`
- `yum` -> well...we'll talk about that later
This is a hack to allow using `inject-pkglist` without having to build
the tree first.
Higher-level, I think we can split this back out again if we have a
`-tests` subpackage where we ship the vmcheck testsuite.
All this does is put the immutable bit on the target directory.
The intention is to replace this bit to start:
8b205bfbb9/src/create_disk.sh (L229)
However, the real goal here is to add code in this file
to handle redeploying the rootfs for Fedora CoreOS which
combines OSTree+Ignition:
https://github.com/coreos/fedora-coreos-tracker/issues/94
Basically doing this in proper Rust is going to be a lot
nicer than shell script in dracut modules. Among other
details, coreutils `mv` doesn't seem to do the right thing
for SELinux labels when policy isn't loaded.
Teach `UpdateDeployment` to make use of libostree's staging lock and
then add a `FinalizeDeployment` API to perform the final unlock &
reboot.
I also added a hidden CLI to make testing this easier, but also because
it's likely the FCOS-agent-yet-to-be-named will just end up using the
CLI to keep it simple.
Closes: #1748Closes: #1814
Approved by: lucab
Perhaps an unexpected side benefit of slow compilation processes
is that one has an opportunity to reflect and ponder.
I realized during exactly such a moment that since we moved
`cbindgen` out of our library build, there's no need to wait
for the library to be built before we can start building the C
code.
This is a notable local quality-of-life development improvement.
Closes: #1665
Approved by: jlebon
This currently requires a `--i-know-this-is-experimental` flag;
I know it'd be a bit more consistent to have it under `ex`, but
what feels weird about that is *most* of the `ex` commands people
use are client side. This is where we want it to ultimately end
up.
We've landed a lot of prep patches, but I know there's still
a notable amount of code duplication with `compose tree`. What's
left is about ~700 lines but it's mostly not hard/complex code
anymore.
In the future, I'd like to extract more of the compose code
to a `rust/src/compose.rs` or so, but I think this is sustainable
fow now.
My high level goal is to get this into coreos-assembler and stand
up a Silverblue build that uses it.
Closes: #1512
Approved by: jlebon
The `--frozen` stuff ends up being annoying when switching
branches. What we're really trying to protect against here
is the `sudo make install` problem, so let's test for that
more directly by verifying the uids.
(The previous code was also totally broken as it used `$` where
`$$` should have been in multiple places)
Closes: #1601
Approved by: cgwalters
I often am editing just the Rust code, and want the fast iteration
feedback of a `cargo test` - don't want to pay the cost of full
optimization (particularly LTO) for the release build, and I
*just* want to run the Rust tests.
Basically if you're editing our Rust code a lot, this target is
your friend.
Closes: #1585
Approved by: jlebon
This is analogous to commit c62058e548
which propagated `V=1` into `cmake`. Except if the build *isn't*
verbose (for local development), let's not force `--verbose` on
for Rust.
Closes: #1583
Approved by: jlebon
The problem is building bindgen as part of our single run
locks serde to way old versions, and I want to use newer versions.
Since Fedora will now again ship a `cbindgen` package, let's
also support using it if we find it, saving ourselves
the cost of building it.
For distros that don't ship it (e.g. CentOS) for CI purposes
we build it. For downstream builds that are offline, rather
than vendor the cbindgen sources like we do with our main Rust,
let's just vendor the `rpmostree-rust.h` file as was suggested
in https://bugzilla.redhat.com/show_bug.cgi?id=1608670
Closes: https://github.com/projectatomic/rpm-ostree/issues/1557Closes: #1573
Approved by: jlebon
Prep for adding a new toplevel rojig command. It's also just
cleaner to avoid cluttering up the main compose logic with
distractions like the `_legacy_prep_dev()` bits.
Closes: #1564
Approved by: jlebon
For local development, I want to be able to e.g. update `Cargo.toml`
or switch branches and not have to `rm -rf target`.
Let's tweak the logic here so we only pass `--frozen` if the ownership
of the dir is different.
Probably an even better fix would be to just error out, but
this is a conservative tweak.
Closes: #1563
Approved by: jlebon
If we're going to scale out our oxidation, let's follow
the path of Firefox (and other projects) further and use
cbindgen: https://github.com/eqrion/cbindgen
It's actually nice that `cbindgen` is packaged today in Fedora,
but I doubt it is elsewhere; we may end up needing to push
that forward, or just vendor it via a `build.rs` script and Cargo.
I chose to rename things to `ROR`/`ror_` since it's shorter. I
am tempted a bit to rename our internal functions to just `ro_` to
or so.
Closes: #1516
Approved by: jlebon
https://fedoraproject.org/wiki/Changes/RemoveExcessiveLinking
broke our build, since Rust doesn't yet have a way to express
the fact that the static library has dynamic dependencies.
(AIUI this is actually something libtool can handle with `.la` but eh)
Closes: #1522
Approved by: cgwalters
This teaches the client to fetch packages from URLs directly so that one
doesn't have to `curl` first and then install. Supported anywhere
package filenames are allowed (notably: `install` and
`override replace`).
One neat things about this is that we download the file into an
`O_TMPFILE` and then pass on ownership of that fd directly to the
daemon. So at no point are the packages actually laying visible on the
system. (Assuming the filesystem supports `O_TMPFILE` that is).
This adds direct linking to libcurl and openssl, two libraries which we
were already pulling in indirectly.
Closes: #1508
Approved by: cgwalters
When building in `debug` mode, `RUST_DEBUG` was still turned off because
`rust_debug_release` was set to `yes`, not `debug`.
Fix this by tweaking how `--enable-rust-debug` works: when it's *not*
provided, we default to the `$CFLAGS` detection logic. Otherwise, it
overrides it.
Closes: #1514
Approved by: cgwalters
As something that manages your base operating system, we care
about reliability, predictability, as well as performance and
low-level access to native operating system facilities. The
C programming language is great for the latter two, but fails
at providing a truly memory-safe environment. Rust is fairly
unique in providing a language that doesn't carry a runtime,
so we can gradually "oxidize" and convert our C code without
imposing additional overhead. It's also got a lot of modern
design niceties, like not having a null pointer.
Let's pull the trigger here and hard require Rust. It's the
programming language I personally want to be primarily writing in for
years to come.
This is also in line with a recent trend of reducing our
experimental/optional matrix.
Closes: #1509
Approved by: jlebon
It is actually really nice that there's One Canonical Style, even
if I sometimes don't like some details of what rustfmt does.
Closes: #1444
Approved by: jlebon
It makes more sense to have the include live next to the associated
code, just like we do with C, even though the `cargo build` doesn't
touch it.
Closes: #1444
Approved by: jlebon
Add a new `reset` command that makes it easy to blow away all
customizations: overlays, overrides, and initramfs. One can use flags to
only reset some of the customizations.
I placed this under `ex` out of conservatism. It's a pretty simple
command with simple behaviour, though the features it relies on
(no-layering, no-initramfs) are brand new. We can move it out of there
in a release or two?
Closes: #1387Closes: #1419
Approved by: cgwalters
Let's modernize and start supporting YAML treefiles. I'll dare make the
sweeping generalization that most people would prefer reading and
writing YAML over JSON.
This takes bits from coreos-assembler[1] that know how to serialize a
YAML file and spit it back out as a JSON and makes it into a shared lib
that we can link against. We could use this eventually for JSON inputs
as well to force a validation check before composing.
If we go this route, we could then turn on `--enable-rust` in FAHC for
now and drop the duplicate code in coreos-assembler.
[1] https://github.com/cgwalters/coreos-assemblerCloses: #1377
Approved by: cgwalters
This was caught by the abicheck in Fedora; since we were building with default
visibility for `librpmostreepriv.la` which was linked statically into the public
library, we'd end up with lots of internals as public ABI.
Fix this by using `-fvisibility=private` for the libpriv build and for good
measure elsewhere so we remember to use it by default.
Closes: #1320
Approved by: jlebon
This renames the remaining C files, tests, etc. There are only
a few hits for `jigdo` left; changing them would be a format break,
so let's wait to do that until we need to.
Closes: #1279
Approved by: jlebon
I saw kalev's slides reference `rpm-ostree unlock`; this patch makes it exist.
In general, people have a hard time (understandably) grasping the distinction
between ostree and rpm-ostree; along with the goal of making ostree really
"libostree", let's start wrapping more commands where it makes sense.
I also took this opportunity to have a more descriptive name; it's important
to note that it *doesn't* overlay `/etc`, `/var`, or `/boot` for example.
Closes: #1233
Approved by: jlebon
Right now the fact that one can only cancel via `Ctrl-C` of an existing client
process is rather frustrating if for example one's ssh connection to a machine
drops. Now, upon reconnecting, one can easily `rpm-ostree cancel` a hung update
or whatever rather than doing the more forcible `systemctl stop rpm-ostreed`
(which is safe of course, unless livefs is involved).
Closes: #1019
Approved by: jlebon
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
I think the `ex container` path supercedes this; it was really just a demo, and
having it around is annoying since I want to change the importer API and I have
to change it here too.
Closes: #1116
Approved by: jlebon
This is initial groundwork for https://github.com/projectatomic/rpm-ostree/issues/594.
This commit sets up most of the required
front end logic( arg parsing, transaction handling), and will
be used in the following commits.
There is nothing really fancy in this commit, as most of the code
shares the similar style between other dbus related commands.
Closes: #1013
Approved by: cgwalters
This is essentially the `dnf/yum makecache` equivalent for rpm-ostree.
To complete the picture, this goes hand in hand with the `-C`
equivalent, which is added in the next patch.
Closes: #1035
Approved by: cgwalters
Spawn pkttyagent when trying to call a method that may require
authentication to give users a chance to provide auth right from the
terminal.
Since we're now relying on polkit for authorizing most of the OS
interface methods, let's drop the root check on those.
Closes: #894
Approved by: cgwalters
This is one more step towards making rpm-ostree more powerful in its
quest to be the ultimate *hybrid* image/package system. Package layering
allows us to add packages on top of the base package set received from
the content provider. However, we're not able to remove or replace
packages in the base set itself.
This patch introduces a new `override` command, which is for now nested
under the experimental `ex` command. The `override` command will allow
users to modify the base package set itself. The first implemented
subcommands are `remove` and `reset`.
A stub has been provided for the more useful `replace` subcommand,
though much of the needed logic for that operation are implemented in
this patch as part of the `remove` subcommand.
Part of: https://github.com/projectatomic/rpm-ostree/issues/485Closes: #797
Approved by: cgwalters
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639Closes: #652
Approved by: jlebon
The goal is to consolidate our "experimental" functionality under one
subcommand. This makes it easier to determine when things "graduate"
to permanent-stability status under the main command line.
Closes: https://github.com/projectatomic/rpm-ostree/issues/682Closes: #683
Approved by: jlebon
There are two main issues right now; first, we don't pick up manual changes to
`.origin` files, which occurs when one needs to sed it to remove `unconfigured`
for example. Second, we need to reload changes to the remotes.
Closes: #598
Approved by: jlebon
We sometimes talk about using `ostree admin undeploy`, but that
doesn't know about the pkgcache, and hence space there leaks
until the next rpm-ostree operation.
Just for this, we need to expose a cleanup command (and API). But
we also need to support cleaning:
- repomd
- downloads (repo/tmp)
So let's start implementing that.
Closes: #614
Approved by: jlebon
I debated just putting this in the supported list, but decided against
it in the end. This really should be something that happens
transparently, and if it doesn't then something else is probably wrong.
Closes: #617
Approved by: cgwalters
We want people to use the libostree API for things like this. Further, the
`rpm-sign` tool that this calls is Red Hat internal, so it doesn't make sense to
have a public wrapper for it.
Closes: https://github.com/projectatomic/rpm-ostree/pull/152Closes: #607
Approved by: jlebon
The actual problem I am trying to fix with this is fallout from the
introduction of `/usr/libexec/rpm-ostreed`, which required a SELinux
policy change. Specifically for CentOS, the base policy is rev'd
slowly.
My hope was that by merging the daemon code back into `/usr/bin/rpm-ostree`
which is labeled `install_exec_t`, starting via systemd would do
the right thing. It turns out that doesn't happen.
Now later, I'm picking this patch back up because I want to do multprocessing in
the daemon (and in the core), and it makes sense to share code between them,
because multiprocessing will need to go through a re-exec path.
Another benefit is we avoid duplicated text (libglnx, internal helpers) between
the two binaries.
Closes: #292
Approved by: jlebon
Currently we push for a model where the initramfs is
generated (in non-hostonly mode), and merely replicated.
However, to support a few unfortunate corner cases like dm-multipath which wants
to inject a config file into the initramfs, we need to support regenerating it
client side too.
Down the line, we'll need this to support overriding the kernel too.
This changes things in the core to add the concept of an "empty"
`RpmOstreeContext`. I initially tried skipping it, but that was too much
duplication. We still want all of the core ostree-related logic that lives in
that code too.
The treespec bits barfed if the spec didn't have a `tree/packages` key. It was
simplest to change that to allow it - and because that was the only case where
we errored out in parsing, I dropped the error handling.
There was another place in the upgrader that now needed to be fixed to handle
transitioning from just regenerating initramfs to not.
Closes: #574
Approved by: jlebon
See https://github.com/projectatomic/rpm-ostree/issues/405
This patch adds an (off by default) `--enable-new-name` build option
which currently defaults to `nts`. This is purely additive, and
the intention is that we'll support the rpm-ostree name in
perpetuity most likely.
At the moment, we add a new name for:
- /usr/bin/$name
- The systemd unit file
But we notably *don't* attempt to add a new name to the DBus API,
as it'd be a lot more invasive of a patch, and less payoff (it's
mostly just programs/scripts that interact with the DBus).
Closes: #497
Approved by: jlebon
So I was trying to hack on my host's copy of rpm-ostree inside a pet
docker container, but ran into a conflict with libhif since dnf uses
it. I think we basically need to *always* build the bundled path,
rather than what I'm doing with CAHC and FADC where it's built as a
regular RPM.
It's not really sustainable right now for us to have both bundled and
not-bundled build paths - and we need to support co-installation with
dnf.
Another major issue is that we want to version lock with libhif -
right now our CI and both CAHC/FADC track libhif master, but that
means everything breaks if libhif breaks and we don't immediately
port.
git submodules solve all of these problems - the same as we're doing
with libglnx.
libglnx is *designed* for use as a git submodule, where as libhif
needs to support being both bundled and not-bundled. So we end up
with some hacks on our side, but I think it's all not too bad. I've
marked build rules with `# bundled libhif` so we know where to find
them later when libhif is stable.
Closes: #357
Approved by: jlebon
I've found it's a lot less code to have multiple builtins share live
in the same `.c` file where they can share things like options.
Also, rename `pkg-delete` -> `pkg-remove` since the canonical antonym
of `add` is `remove`.
Closes: #345
Approved by: jlebon
According to tmpfiles.d(5), files should follow the convention
<package>.conf or <package>-<part>.conf. So we rename
tmpfiles-ostree-integration.conf to rpm-ostree-0-integration.conf.
The 0 index is so that the autovar conf created by postprocess is
sourced *after* this one, so that `integration.conf` has higher
precedence if there are duplicate entries.
Closes: #325
Approved by: cgwalters
This builds upon the earlier prototype in
https://github.com/cgwalters/atomic-pkglayer
The `.origin` file says for a replicated installation:
[origin]
refspec=local:rhel-atomic-host/7/x86_64/standard
If you then run `rpm-ostree pkg-add strace`, it will result in a new tree with:
[origin]
baserefspec=local:rhel-atomic-host/7/x86_64/standard
[packages]
requested=strace;
Work still remaining here is to teach `rpm-ostree status` and
`rpm-ostree upgrade` about this.
Closes: #289
Approved by: cgwalters
This is just a tech demo. Example usage:
```
mkdir -p ~/.cache/rpmostree-containers
cd ~/.cache/rpmostree-containers
rpm-ostree container init
cp /etc/yum.repos.d/CentOS-Core.repo rpmmd.repos.d
rpm-ostree container assemble bash
rpm-ostree container assemble httpd
```
This is part of taking over from librpm. The most important high
level goal is fully unprivilged operation.
Right now we're basically starting to do what
http://libguestfs.org/supermin.1.html does, except in C, and
faster.
There's no reason that `compose tree` should require privileges.
However right now, things like `%post` scripts will want to run in the
target root - so we'd have to require `linux-user-chroot`.
Regardless of unprivileged operation though, another major thing we
can do is use our control over the unpacking process to do a lot more
sophisticated caching. We can build up a precise mapping of (rpm
ENVR, file path, selinux label) -> object and avoid rechecksumming
each time.
And even for files that aren't known, we can parallelize commit with
unpacking, etc. (Ok assuming treecompose-post won't mutate anything).
I'd like to experiment with different things that end up
reusing chunks of the rpm-ostree internals, such as libhif, the
helpers we already have around RPM, etc.
In this particular case I'm experimenting with unpacking/committing
RPM packages as non-root. Eventually most of this should end up as
internal private shared library, but it's convenient to have an
ABI-unstable and hidden "internals" command to run things directly.
This commit though just adds the scaffolding for "internals".
This is a step forward to deduplicating; the client tooling now calls
into the public API for diffs, rather than using the older internal
function.
Note: this patch also links the client against the public library.
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
We currently have an internal-only library, but the sources for it are
in the same dir as the app. For future work on a public shared
library, we'll need a clearer source structure.
Start by just renaming the app files into `src/app/`, and the internal
private library into `src/libpriv/`, with the appropriate
`Makefile.am` changes.
Closes: https://github.com/projectatomic/rpm-ostree/pull/123
The high level goal is to deprecate libgsystem. I was trying to share
code between ostree/rpm-ostree, but it was too painful to commit to
forver frozen ABI for new utility APIs.
The git submodule approach will much more easily allow breaking
API/ABI, and iterate on APIs until they either land in GLib or not.
Note that libglnx will not use GFile*, so a full port to it will
involve also not using that. Thus, it will be necessarily
incremental; in the meantime we'll link to both libgsystem and
libglnx.
Remove redundant function _rpmostree_pull_progress().
Bumped ostree requirement to 2014.13, but this isn't quite right because
we actually need (unreleased) 2014.14. Post-release version bumps would
be useful here.
