Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux