cgwalters left a comment (rpm-software-management/rpm#2503)
We should probably track rpm+chroot discussions in a dedicated issue, but the
other really big thing about `chroot()` is that it massively complicates using
rpm as a library because the process basically cannot reliably do anything else
(in another thread) while a chroot is active.
We've mostly gotten away with things so far because the 90% case for e.g. dnf
and PackageKit type software is operating on the live root, so it's just
`chroot(/)` which is a no-op, so things are fine.
And most things using `rpm --installroot` are headless scripts that aren't
doing anything else.
But for e.g. rpm-ostree, we *always* operate on an alternative root by default,
we don't live mutate the running system. And in rpm-ostree we always act as a
DBus daemon exposing progress information, etc. These two things combined are
among the biggest reasons rpm-ostree doesn't use the main librpm transaction
code (installing files and running scripts). In the end this is would likely be
possible to work around by forking a dedicated helper process that runs librpm
code and talking to it over IPC, ensuring that IPC layer is "thin" and never
e.g. loads anything dynamically from the filesystem at all after starting
(config files, or invoke gettext() etc).
But it'd fix a whole lot of things at once if rpm stopped using chroot(), and
then we could go back to using NSS just fine.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2503#issuecomment-2674772849
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/pull/2503/c2674772...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
