Package: wnpp
Severity: normal
X-Debbugs-Cc: ost...@packages.debian.org, debian-de...@lists.debian.org,
sjo...@debian.org, m...@debian.org
Control: affects -1 + src:ostree
I request assistance with maintaining the ostree package.
(Other Uploaders cc'd.)
Package description:
libostree provides a library and tools for managing bootable, immutable,
versioned filesystem trees. It is like git in that it checksums
individual files and has a content-addressed object store; unlike git,
it "checks out" the files using hardlinks into an immutable directory
tree. This can be used to provide atomic upgrades with rollback, history
and parallel-installation, particularly useful on "fixed purpose"
systems such as embedded devices.
src:ostree currently has one RC bug, #1098951, a test failure involving
its interaction with GPG signature verification: updates to GPG
have caused it to report a missing key (GPGME_SIGSUM_KEY_MISSING,
OSTREE_GPG_ERROR_MISSING_KEY, "Can't check signature: public key not
found") instead of an expected failure mode like "key expired". I have
been unable to identify whether this is a GPG bug or an ostree bug, and
would particularly welcome help with this.
I first uploaded this package in 2016 as a dependency of Flatpak. It
is team-maintained by the Utopia team (approximately a "freedesktop.org
stuff" team) and has other Uploaders, but in practice I have effectively
been maintaining it alone, which was not really my intention.
Some Debian-derived operating systems like Endless OS (and
non-Debian-derived OSs like Fedora Silverblue) make use of ostree for
their OS binaries, but I don't use it in that mode myself and have no
particular expertise in how that works, so it would be helpful if someone
who *is* using it in that mode could assist.
The upstream developer is helpful and pleasant to work with, but does not
always prioritize the same things that Debian requires us to prioritize.
The library is written in a fairly conventional GLib/GNOME style that
will be familiar to developers of GTK-based desktops. It currently still
uses Autotools; I suspect that upstream would be receptive to the idea
of porting the build system to Meson if someone did the work, but I have
been unable to allocate time to do that myself.
One potential future direction is that the upstream developer is putting a
lot of work into Rust bindings, and it is possible that libostree itself
might eventually contain (or even consist entirely of) Rust code. I do
not know Rust and realistically I am unlikely to find the time to learn
it any time soon, so if that rewrite does occur, I will be unable to
maintain the package competently.
Thanks,
smcv
