Re: New top-level dir: /state [WAS: 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 Sunday, January 16, 2022 11:16:57 PM EST Chris Murphy wrote:
> On Sun, Jan 16, 2022 at 3:59 PM Peter Boy <pboy@xxxxxxxxxxxxx> wrote:
> > > Am 14.01.2022 um 23:51 schrieb Fabio Valentini <decathorpe@xxxxxxxxx>:
> > > 
> > > 
> > > Wait, I thought this change was about making the path consistent
> > > within Fedora variants?
> > 
> > The question still is whether this is actually useful and beneficial.
> 
> If you value Fedora having a snapshot and rollback scheme of some
> kind, it's useful and beneficial.  If you don't, then the change is
> neutral because it has not a single technical downside presented so
> far - just emotive ones.

I'm a little concerned about what this increased writing to /usr, which many 
people have on a SSD, will do. I have everything that gets written to with 
any regularity on spinning disks. Everything else is SSD.

I have to agree with Chris Adams that rpms own things on many top level 
directories. I have rpms that own programs/files that live on /opt and other 
top level directories. I also agree that most programs cannot recreate their 
directory paths and consider it's absense to be a catastrophic failure. 

I also see things like kmail which uses mariadb as it's storage. It 
occassionally contains migration scripts to change the format of the 
database. It never has a migration script to go backwards. We do the same 
thing with fapolicyd and its lmdb backing storage. We migrate forward, but we 
never allow backwards migration. To roll back fapolicyd, you'd need to 
snapshot /var and roll it back. But since /var has the mail spool and other 
accumulated data, you'd risk losing lots of stuff if /var was rolled back.

I'd think the solution for image based distros is to put the rpmdb in /usr/
lib/rpm and bind mount it to /var/lib/rpm. Doing it this way means no changes 
are needed.

-Steve

_______________________________________________
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