(Adding the correct Daniel Mach email address, he moved from Red Hat to SUSE last month...)
On Thu, Dec 9, 2021 at 10:11 AM Chris Murphy <li...@colorremedies.com> wrote: > > On Thu, Dec 9, 2021 at 5:01 AM Jaroslav Mracek <jmra...@redhat.com> wrote: > > > > Hello Chris, > > > > On Tue, Dec 7, 2021 at 5:01 AM Chris Murphy <li...@colorremedies.com> wrote: > >> > >> Hi RPM and DNF folks, > >> > >> I have a draft change proposal for review and comment, i.e. it's not yet > >> set to be published to Fedora devel@. It's a bit thin, but I expect to > >> fill in more detail following discussion in this thread. > >> > >> https://fedoraproject.org/wiki/Changes/RelocateRPMDNFToUsr > > > > > > The change is not so simple. It is not only the movement of files from one > > location to another one. We store more types of data in that location - > > history database (sqlite), module failsafe data (yamls). In future we will > > store system state data (toml). Data is not only modified after RPM > > transactions but also by module and mark commands. What I want to say is > > that the change will be painful but in the proposal there are limited > > benefits. > > I'm pretty sure I'm generally opposed to the idea of logs being rolled > back (in a snapshot and rollback regime). Logs should always carry > forward. Ideally, indicate relevant things like rollbacks in the log, > because rolling back a log is a form of data loss. The history > database sounds more like a log than not. So I'm getting squeamish > about locating that somewhere else. Whereas system state information, > if it's primarily describing /usr, sounds like it needs to get > somewhere in /usr. > The history database is basically a transaction database like the rpmdb is. It maps rpmdb transactions to dnf actions. So if you're rolling back the rpm-managed content, it still makes sense to roll back the history database, since that's the state of the system. It's not terribly useful if the matching rpmdb transactions don't exist in the rpmdb. That said, the dnfdb is only *important* to move because it's required for modularity stuff to work properly. Otherwise, it's not a huge deal one way or another. > Similar to openSUSE, design efforts around a default snapshot and > rollback regime in Fedora are complicated when anything in /var > depends on the state of /usr, and vice versa. As independent and > interchangeable as they can be, I think the better. > > > There is also a question in which location DNF can move data. proposed > > `/usr/lib/sysimage/dnf` is maybe not the best one. > > What are some alternative suggestions? > > > >> Fedora 36 seems like a good time to do this. What do you think? > > > > > > I don't think it is a good time to perform such a change from a DNF > > perspective. We have a plan to introduce a major update to Fedora 38, > > therefore it is a better time frame for such a change. > > Is it better, worse, or indifferent if the RPM database location were > changed in Fedora prior to any DNF change? > It won't matter. That's how it happened in openSUSE anyway. The rpmdb path change happened several years earlier, and I changed the dnfdb path in openSUSE at the top of the year as part of making the DNF stack work properly on MicroOS. https://code.opensuse.org/package/libdnf/c/37cdf99c506a7a2189ba26527d43665437c1db86 https://code.opensuse.org/package/dnf/c/24888ad21af0081e7432468d1aadfafd46e23526 -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
