Subprocessing a transaction would make this much more brittle, since it would
expose RPM to weaknesses in POSIX itself wrt system software data replacement.
Think for example if rpm is upgrading rpm: having a separate binary means that
we need to design a complex method to handle that the rpm binaries are being
replaced, rather than relying on the in-memory program data footprint that
comes from DNF using librpm and holding it in memory while it works through
everything.
RPM already has locking semantics to implement a "write once, read many" setup,
so I'm not sure we actually _need_ to do much more than beef this up with the
SQLite database backend.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1526#issuecomment-772187553
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
