On Wed, 2021-12-29 at 12:57 -0500, Neal Gompa wrote: > On Wed, Dec 29, 2021 at 12:48 PM Gordon Messmer > <gordon.messmer@xxxxxxxxx> wrote: > > > > On 12/29/21 07:26, Vitaly Zaitsev via devel wrote: > > > On 29/12/2021 16:01, Ben Cotton wrote: > > > > Currently, the RPM databases is located in `/var`. Let's move it > > > > to > > > > `/usr`. The move is already under way in rpm-ostree-based > > > > installations, and in (open)SUSE. > > > > > > It will break FHS compatibility. /usr must contain read-only data. > > > > > > If /usr really is read-only, then it probably doesn't matter where > > the > > rpmdb is, since packages can't be installed (generally). > > > > Moreover, for systems where /usr is read-only and/or shared > > (especially > > stateless systems), having the rpmdb on /usr seems like the most > > rational place for it, if one expects to be able to use rpm to query > > the > > package list. Otherwise, there is an implicit coupling of /usr and > > /var/lib/rpmdb that requires two mounts rather than one. > > Bingo. It's generally accepted that the RPM database changes when the > system state changes. And if the system state is not allowed to > change, the rpmdb should not either. The bigger problem is that having > the RPM database in /var makes it much harder to correctly implement a > boot-to-snapshot scheme for Fedora Linux that reasonably maintains > system state properly once /var is carved out. you just need change to change the default --dbpath of rpm [1] , i.e, I suggest instead change default location of rpm , change the dbpath configuration for the atomic images, is just one idea . [1] man rpm --dbpath DIRECTORY Use the database in DIRECTORY rather than the default path /var/lib/rpm > The reason that /var > *isn't* carved out by default with our Btrfs configuration is because > of the RPM database. Once the RPM database is moved, it becomes > possible to split /var into its own subvolume and make it trivial to > configure a full boot-to-snapshot system leveraging the technologies > we have available to us. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Sérgio M. B. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
