This API is push rather than pull, which makes it much more
suitable to use cases like parsing a tar file from external
code.
Now, we have a large mess in this area internally because
the original file writing code was pull based, but static
deltas hit the same problem of wanting a push API, so I added
this special `OstreeRepoBareContent` just for writing regular
files from a push API.
Eventually...I'd like to deprecate the pull based API,
and rework things so that for regular files the push API
is the default, and then `write_content_object()` would
be split up into archive/bare cases.
In this world the `ostree_repo_write_content()` API would
then need to hackily bridge pull to push and it'd be
less efficient.
Anyways for now due to this bifurcation, this API only
works on non-archive repositories, but that's fine for
now because that's what I want for the `ostree-ext-container`
bits.
Continuation of the addition of `ostree_repo_write_regfile_inline()`.
This will be helpful for ostree-rs-ext and importing from tar, it's
quite inefficient and awkward for small files to end up creating
a whole `GInputStream` and `GFileInfo` and etc. for small files.
Although people are likely not deploying on 32 bit x86 anymore,
deploying on 32 bit armv7 is still often used. Add back an i386 build on
debian to try to catch 32 bit bugs in CI.
Currently the Ubuntu builds are stuck waiting for an answer on what
timezone to use. That could be fixed, but generally the way to do these
types of installs is to set the DEBIAN_FRONTEND environment variable to
`noninteractive` so that debconf just chooses a default. This is what
debootstrap does, for instance. I tested installing tzdata on a local
focal container this way and it just chooses `Etc/UTC` as the timezone.
When working on ostree-ext and importing from tar, it's
quite inefficient and awkward for small files to end up creating
a whole `GInputStream` and `GFileInfo` and etc. for small files.
Plus the gtk-rs binding API to map from `impl Read` to Gio
https://docs.rs/gio/0.9.1/gio/struct.ReadInputStream.html
requires that the input stream is `Send` but the Rust `tar` API
isn't.
This is only 1/3 of the problem; we also need similar APIs
to directly create a symlink, and to stream large objects via
a push-based API.
I was going to add some new API and I noticed that this function
never returns an error; presumably at one point it did, but
not anymore. It simplifies the code flow noticeably
to remove that.
If you don't configure with --enable-gtk-doc, these won't be included in
the generated .gitignore. If you later configure with --enable-gtk-doc
in the same checkout, they'll show up as untracked files. Include them
in GITIGNOREFILES to ensure they're always added regardless of configure
options.
Like the top level .gitignore, there's no reason to track this if it's
being generated automatically. It only produces spurious diff changes
that you almost certainly don't want.
It was added for the collections bits, but we made that stable.
It's now just cruft and we're very unlikely to reuse the infrastructure
again.
Motivated by a unit test failure when running from a tarball:
https://github.com/ostreedev/ostree/issues/2313
Simon McVittie
Colin Walters
Luca Bruno
Jonathan Lebon
Benjamin Gilbert
Dan Nicholson
Luca Bruno