Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
> Am 17.01.2022 um 05:16 schrieb Chris Murphy : > > On Sun, Jan 16, 2022 at 3:59 PM Peter Boy wrote: >> >> >> >>> Am 14.01.2022 um 23:51 schrieb Fabio Valentini : >>> >>> >>> 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. The loss of LSB / FHS compliance is by no means "just emotive", nor is the consequence of probably having to adapt an unknown number of scripts, backup routines, etc. . As you stated in a previous post, LVM snapshot is „under-developed“ and therefore currently not useful. Is there another snapshot & rollback tool in Fedora repository I can use out of the box (after I moved rpm db to /usr)? Unfortunately, I don’t know one. Currently I would have to create a LVM snapshot and a manually crafted selective backup of files and subdirectories. And test all the stuff. Not particularly practical. I guess, an achievement of a truly viable snapshot and rollback system for file-based distributions requires far a greater number of relocations than just the rpm db. The article of a (presumably) Suse employee I’m trying to retrieve (see an earlier post of mine) offers a proposal for this very purpose (including a backwards compatibility link system). This would eventually end up in an FHS 4.x. Moving the rpm db alone adds only disadvantages to file-based distributions, not a single advantage. And it is not neutral either. In the end, we don't really need to do anything. If I understand correctly, rpm-ostree is already implementing the change anyway, without any change voting, and everyone else will continue as before, following LSB/FHS and the current Fedora guidelines. > Again if you see no value in snapshots/rollbacks, you don't see the > advantage. If you like the idea, then you'd also necessarily come to > realize that some pressure on organizing files into locations with > compatible life cycles, so those locations can be independently rolled > back. I see a lot of value in snapshot&rollback systems. And I see not only „some“ pressure (or better requirements) to reorganise files into different locations. The rpm db is far from sufficient. The proposal mentioned above did exactly that, but rpm db did not end up in /usr but together with parts of /var and /etc somewhere else I don’t remember in detail. And if we make adjustments to achieve a snapshot/rollback system, then we should do it right and not stop halfway unfinished. Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
> Am 17.01.2022 um 05:17 schrieb Chris Murphy : > > On Sun, Jan 16, 2022 at 4:34 PM Peter Boy wrote: >> >> >> @Neal, I remember a Suse employee made once (about a year ago) a proposal to >> slightly modify FHS to better separate distro specific from local specific >> content, especially in /etc. Unfortunately I can't find the link again. Do >> you happen to know if that was related to Suse's snapshot+rollback scheme? > > Maybe this: > https://github.com/lnussel/lnussel.github.io/blob/fs/_posts/2020-12-16-fslayout.md > Yes, that the right direction. I’ll start my search from that. Thanks Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Sunday, January 16, 2022 11:16:57 PM EST Chris Murphy wrote: > On Sun, Jan 16, 2022 at 3:59 PM Peter Boy wrote: > > > Am 14.01.2022 um 23:51 schrieb Fabio Valentini : > > > > > > > > > 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Sun, Jan 16, 2022 at 9:36 PM Chris Adams wrote: > > Once upon a time, Chris Murphy said: > > 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. > > It's only beneficial for snapshots if you believe that only /usr > matters, which I don't believe is true. It might be true that it's the only one that should matter, if you care to have the benefit of a clear cut snapshot and rollback design. This is the /etc/fstab for (open)SUSE Tumbleweed. $mainfsuuid / btrfs defaults 0 0 $mainfsuuid /varbtrfs subvol=/@/var 0 0 $mainfsuuid /usr/local btrfs subvol=/@/usr/local 0 0 $mainfsuuid /srvbtrfs subvol=/@/srv 0 0 $mainfsuuid /root btrfs subvol=/@/root0 0 $mainfsuuid /optbtrfs subvol=/@/opt 0 0 $mainfsuuid /home btrfs subvol=/@/home0 0 $mainfsuuid /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0 $mainfsuuid /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0 $mainfsuuid /.snapshots btrfs subvol=/@/.snapshots 0 0 $swapfsuuid swapswap defaults 0 0 $espfsuuid /boot/efi vfat utf8 0 2 It lacks a separate line for /var/tmp/rpm, which it would otherwise need, because the rpmdb is in /usr. It looks like this because /usr isn't the only thing that's important. These carve outs exist because it was easier to do with Btrfs subvolumes (effectively bind mounts behind the scenes) than (a) with individual file systems or (b) committing to reorganizing the filesystem hierarchy. Now (open)SUSE is doing the hard work to reorganize the filesystem hierarchy where RPM only touches /usr. If we're feeling bold and maybe even brazen, maybe we'd pull everything out of /usr /var /etc that can be called 'the system'. Specifically, that which is system critical for the purpose of booting and startup. Things that get us to a working login prompt, but not beyond that (or at least not much beyond it). Stick all of that into a new top-level directory called "system". Within that could be usr/ var/ etc/ if you want. This "system" subvolume or LV is what would be subject to snapshot and rollback. This could be done with metadata defining what individual files are "system critical" so that 'dnf history rollback' could do a fine grained revert for such those files. But that presumes we can even boot to a system sufficiently working that this command could succeed. I think it's better to have a system that's prepared for the possibility an update can introduce trouble, and has the ability to detect failure and reboot to a previous known working state. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
Once upon a time, Chris Murphy said: > 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. It's only beneficial for snapshots if you believe that only /usr matters, which I don't believe is true. It is not neutral, because it does change things from long-standing defaults. It's also a change away from upstream, which normally I thought Fedora preferred to avoid unless there's a significantly compelling reason. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Sun, Jan 16, 2022 at 4:34 PM Peter Boy wrote: > > > > > Am 17.01.2022 um 00:09 schrieb Neal Gompa : > > > > On Fri, Jan 14, 2022 at 5:51 PM Fabio Valentini > > wrote: > >> > >> …. > > > > openSUSE originally did the move because standard openSUSE has a > > snapshot+rollback scheme and tracking the rpmdb is straightforward in > > /usr with all the other system state data. This benefited them for the > > development and release of openSUSE MicroOS a couple years later. > > > > @Neal, I remember a Suse employee made once (about a year ago) a proposal to > slightly modify FHS to better separate distro specific from local specific > content, especially in /etc. Unfortunately I can't find the link again. Do > you happen to know if that was related to Suse's snapshot+rollback scheme? Maybe this: https://github.com/lnussel/lnussel.github.io/blob/fs/_posts/2020-12-16-fslayout.md -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Sun, Jan 16, 2022 at 3:59 PM Peter Boy wrote: > > > > > Am 14.01.2022 um 23:51 schrieb Fabio Valentini : > > > > > > 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. This change also doesn't put pressure on future decisions. It doesn't favor particular ways of snapshotting or rollback mechanisms, doesn't care about what volume manager is being used, etc. > All the arguments for this move that I have read so far explain benefits > related to an image based distribution. I have not seen any advantages of > this move for a file based distribution like Server or Workstation. Again if you see no value in snapshots/rollbacks, you don't see the advantage. If you like the idea, then you'd also necessarily come to realize that some pressure on organizing files into locations with compatible life cycles, so those locations can be independently rolled back. The change is already employed in traditional RPM based (open)SUSE a couple of years, the links to those discussions are in the change proposal. >And when I look at tools like LVM snapshot, I can't see any either. And I >couldn’t find something in a short online search. But maybe I missed >something? Then I would be grateful for some info/links. If anything it benefits LVM more, because each additional carveout on LVM requires a separate file system. On btrfs it's cheap to add subvolumes since they take up no space and instead all share a single storage pool, though it organizationally adds complexity. Would putting /var/lib/rpm on a dedicated LVM LV actually be entertained? I think it wouldn't. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
Once upon a time, Neal Gompa said: > On Sun, Jan 16, 2022 at 6:47 PM Chris Adams wrote: > > Once upon a time, Neal Gompa said: > > > It benefits LVM-based OS snapshotting equally well. However, the > > > tooling for LVM snapshots are under-developed, so it's not used so > > > much for this. > > > > How? Since the standard install uses a single root filesystem that > > includes /usr and /var, I can't see any benefit to it there either. > > It does *now*, but it's not necessarily desirable to keep it that way > if you want this capability. For Btrfs, shuffling subvolumes is cheap. > For LVM, shuffling LVs is a bit more work. I know about LVM snapshots - I used them for years to get point-in-time backups. But that doesn't explain a benefit to splitting /, /usr, and /var into separate filesystems/LVs/whatever. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Sun, Jan 16, 2022 at 6:47 PM Chris Adams wrote: > > Once upon a time, Neal Gompa said: > > It benefits LVM-based OS snapshotting equally well. However, the > > tooling for LVM snapshots are under-developed, so it's not used so > > much for this. > > How? Since the standard install uses a single root filesystem that > includes /usr and /var, I can't see any benefit to it there either. It does *now*, but it's not necessarily desirable to keep it that way if you want this capability. For Btrfs, shuffling subvolumes is cheap. For LVM, shuffling LVs is a bit more work. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
Once upon a time, Neal Gompa said: > It benefits LVM-based OS snapshotting equally well. However, the > tooling for LVM snapshots are under-developed, so it's not used so > much for this. How? Since the standard install uses a single root filesystem that includes /usr and /var, I can't see any benefit to it there either. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
> Am 17.01.2022 um 00:09 schrieb Neal Gompa : > > On Fri, Jan 14, 2022 at 5:51 PM Fabio Valentini wrote: >> >> …. > > openSUSE originally did the move because standard openSUSE has a > snapshot+rollback scheme and tracking the rpmdb is straightforward in > /usr with all the other system state data. This benefited them for the > development and release of openSUSE MicroOS a couple years later. > @Neal, I remember a Suse employee made once (about a year ago) a proposal to slightly modify FHS to better separate distro specific from local specific content, especially in /etc. Unfortunately I can't find the link again. Do you happen to know if that was related to Suse's snapshot+rollback scheme? Thanks Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Sun, Jan 16, 2022 at 5:59 PM Peter Boy wrote: > > > > > Am 14.01.2022 um 23:51 schrieb Fabio Valentini : > > > > > > 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. > > All the arguments for this move that I have read so far explain benefits > related to an image based distribution. I have not seen any advantages of > this move for a file based distribution like Server or Workstation. And when > I look at tools like LVM snapshot, I can't see any either. And I couldn’t > find something in a short online search. But maybe I missed something? Then I > would be grateful for some info/links. > It benefits LVM-based OS snapshotting equally well. However, the tooling for LVM snapshots are under-developed, so it's not used so much for this. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Fri, Jan 14, 2022 at 5:51 PM Fabio Valentini wrote: > > On Fri, Jan 14, 2022 at 7:16 PM Colin Walters wrote: > > > > > > > > On Thu, Jan 13, 2022, at 6:05 PM, Fabio Valentini wrote: > > > > > The path "/usr/lib/sysimage/rpm" does look very out-of-place in > > > non-image-based systems, so *if* we want to move the rpmdb to a place > > > that's consistent across all our Editions, it should also be a > > > location name that makes sense across all Editions. > > > > I don't think we should discount alignment with OpenSUSE. When they > > originally proposed /usr/lib/sysimage I started to write a bikeshed reply > > email (like many that have been posted here) around why /usr/share was a > > bit better but then I said to myself: "You know what? I don't care as long > > as we get it in /usr. Since they're driving the change, and there really > > isn't any technical compelling reason to do something else, it's fine." > > > > Also, proliferation of these paths has a cost; see e.g. > > https://github.com/openSUSE/libsolv/pull/386 > > Though in practice *most* cases will be fine just chasing a symlink from > > /var/lib/rpm. > > Wait, I thought this change was about making the path consistent > within Fedora variants? > I understand that converging on the same path as OpenSUSE makes sense, > but does that mean we should not consider if there's a better > alternative? ... > And the "sysimage" path makes even less sense to me in the OpenSUSE > context, since they don't have an OSTree based variant at all (unless > I am mistaken)? > openSUSE originally did the move because standard openSUSE has a snapshot+rollback scheme and tracking the rpmdb is straightforward in /usr with all the other system state data. This benefited them for the development and release of openSUSE MicroOS a couple years later. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
> Am 14.01.2022 um 23:51 schrieb Fabio Valentini : > > > 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. All the arguments for this move that I have read so far explain benefits related to an image based distribution. I have not seen any advantages of this move for a file based distribution like Server or Workstation. And when I look at tools like LVM snapshot, I can't see any either. And I couldn’t find something in a short online search. But maybe I missed something? Then I would be grateful for some info/links. In the case that there is no benefit for file based distributions, they only suffer the "malefit" of losing FHS compliance and possibly having to adapt administration scripts and routines. Then it would make more sense to move the RPM database only for image based distributions (which has obviously already been done anyway). Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Fri, Jan 14, 2022 at 3:51 PM Fabio Valentini wrote: > > On Fri, Jan 14, 2022 at 7:16 PM Colin Walters wrote: > > > > > > > > On Thu, Jan 13, 2022, at 6:05 PM, Fabio Valentini wrote: > > > > > The path "/usr/lib/sysimage/rpm" does look very out-of-place in > > > non-image-based systems, so *if* we want to move the rpmdb to a place > > > that's consistent across all our Editions, it should also be a > > > location name that makes sense across all Editions. > > > > I don't think we should discount alignment with OpenSUSE. When they > > originally proposed /usr/lib/sysimage I started to write a bikeshed reply > > email (like many that have been posted here) around why /usr/share was a > > bit better but then I said to myself: "You know what? I don't care as long > > as we get it in /usr. Since they're driving the change, and there really > > isn't any technical compelling reason to do something else, it's fine." > > > > Also, proliferation of these paths has a cost; see e.g. > > https://github.com/openSUSE/libsolv/pull/386 > > Though in practice *most* cases will be fine just chasing a symlink from > > /var/lib/rpm. > > Wait, I thought this change was about making the path consistent > within Fedora variants? CoreOS/Silverblue/Kinoite ls -l /var/lib/rpm lrwxrwxrwx. 1 root root 19 Dec 6 12:32 /var/lib/rpm -> ../../usr/share/rpm $ ls -l /usr/share/rpm total 52684 -rw-r--r--. 3 root root 53915648 Dec 31 1969 rpmdb.sqlite -rw-r--r--. 5 root root32768 Jan 14 18:10 rpmdb.sqlite-shm -rw-r--r--. 1 root root0 Jan 11 18:51 rpmdb.sqlite-wal $ ls -l /usr/lib/sysimage/rpm lrwxrwxrwx. 3 root root 15 Dec 6 12:23 /usr/lib/sysimage/rpm -> ../../share/rpm This symlink is present on Silverblue but I don't see it on a stock CoreOS image before it's been booted and subject to setup by ignition. $ ls -l /var/lib/rpm -> ../../usr/share/rpm > I understand that converging on the same path as OpenSUSE makes sense, > but does that mean we should not consider if there's a better > alternative? ... I think it's fine to consider alternatives, but the tradeoff might be that (open)SUSE sticks with what they've got. I have no idea but that could be a question posed to them before deciding this. > And the "sysimage" path makes even less sense to me in the OpenSUSE > context, since they don't have an OSTree based variant at all (unless > I am mistaken)? Absent the rpmdb, and ignoring all other considerations like storage and performance cost, could RPM learn to reconstruct the rpmdb? What would it need locally to do that? Would it need to keep rpm package headers and compare to what's installed? Some variation on rpm -Va? The point would be to keep /var/lib/rpm/rpmdb* allow it to be disposable, but with consequences. If rpm packages can be disembodied from their payload, just leaving the metadata, seems like it's plausible to reconstruct an rpmdb from checksums of what's installed versus would could be installed. This raises questions like, garbage collection of all these rpm files, would they be removed when the package is removed? -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Fri, Jan 14, 2022 at 7:16 PM Colin Walters wrote: > > > > On Thu, Jan 13, 2022, at 6:05 PM, Fabio Valentini wrote: > > > The path "/usr/lib/sysimage/rpm" does look very out-of-place in > > non-image-based systems, so *if* we want to move the rpmdb to a place > > that's consistent across all our Editions, it should also be a > > location name that makes sense across all Editions. > > I don't think we should discount alignment with OpenSUSE. When they > originally proposed /usr/lib/sysimage I started to write a bikeshed reply > email (like many that have been posted here) around why /usr/share was a bit > better but then I said to myself: "You know what? I don't care as long as we > get it in /usr. Since they're driving the change, and there really isn't any > technical compelling reason to do something else, it's fine." > > Also, proliferation of these paths has a cost; see e.g. > https://github.com/openSUSE/libsolv/pull/386 > Though in practice *most* cases will be fine just chasing a symlink from > /var/lib/rpm. Wait, I thought this change was about making the path consistent within Fedora variants? I understand that converging on the same path as OpenSUSE makes sense, but does that mean we should not consider if there's a better alternative? ... And the "sysimage" path makes even less sense to me in the OpenSUSE context, since they don't have an OSTree based variant at all (unless I am mistaken)? Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Thu, Jan 13, 2022, at 6:05 PM, Fabio Valentini wrote: > The path "/usr/lib/sysimage/rpm" does look very out-of-place in > non-image-based systems, so *if* we want to move the rpmdb to a place > that's consistent across all our Editions, it should also be a > location name that makes sense across all Editions. I don't think we should discount alignment with OpenSUSE. When they originally proposed /usr/lib/sysimage I started to write a bikeshed reply email (like many that have been posted here) around why /usr/share was a bit better but then I said to myself: "You know what? I don't care as long as we get it in /usr. Since they're driving the change, and there really isn't any technical compelling reason to do something else, it's fine." Also, proliferation of these paths has a cost; see e.g. https://github.com/openSUSE/libsolv/pull/386 Though in practice *most* cases will be fine just chasing a symlink from /var/lib/rpm. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Fri, Jan 14, 2022, at 2:46 AM, Chris Murphy wrote: > > What about /var/lib/selinux? It's owned by the selinux-policy-targeted > package. Even though the files may not change often, it probably needs > to be snapshot and rolled back with revision matching for /usr and > rpmdb. Yep, welcome to https://bugzilla.redhat.com/show_bug.cgi?id=1290659 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
Dne 13. 01. 22 v 15:26 Colin Walters napsal(a): On Thu, Jan 13, 2022, at 7:52 AM, Vít Ondruch wrote: Actually, shouldn't rpm-ostree carry around some copy of the RPM database, which would describe the state of /usr and once the update is successful (or snapshot active?), merge it into the main system RPM database? Apparently, something like this is already happening e.g. for /etc content if I understand it correctly. Or this is the direction in which the /boot will be handled eventually. Or possibly it could be just some linked (possibly just read only) database. I think you are confusing/conflating image based updates and client side snapshots (and relatedly, client side offline updates, which is what https://github.com/OpenSUSE/transactional-update). They are related, but different. I think you are doing unnecessary difference between those. In my view, there is no difference if /usr is read-only, network mounted, expanded from tarball or managed by rpm-ostree. The point is that the location, while being available on the user system, is not modifiable by RPM. The only requirement is that RPM is be able to provides metadata about that location. In this case, it makes perfect sense if the /usr contains some metadata in RPM consumable format (be it RPM database, but that is technical detail, because it could be its simpler version for RO filesystems). Now should there be different locations really managed by RPM, such as /opt, there is no reason why there should not be the system RPM database, which would store location about that parts of the system. To cover this scenario for rpm-ostree, there needs to be done something complex, in your words: If one chooses to engage client side layering (or overrides), rpm-ostree will (each time an upgrade or change is performed) indeed regenerate the rpm database using the "pristine" base image's version of the rpmdb. And I say this is wrong concept (understandably given by technical limitation). RPM in this case should keep using its system database and understand that /usr was delivered by different means, it can't manage the /usr content, but there is the metadata available. In this case, when the base image was updated, the RPM database would not need to be regenerated. However, the base image update could be clocked when e.g. RPM discovered, that it would broke the system dependencies. Vít OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Friday, 14 January 2022 at 00:05, Fabio Valentini wrote: > On Wed, Jan 12, 2022 at 9:45 AM Chris Murphy wrote: > > > > Given the choice, I prefer rpm only touches /usr, which includes > > /usr/var and /usr/etc. > > I must say that, of all the bad suggestions in the multiple threads > this proposal has spawned, I dislike using "/usr/var/" the least. > > The path "/usr/lib/sysimage/rpm" does look very out-of-place in > non-image-based systems, so *if* we want to move the rpmdb to a place > that's consistent across all our Editions, it should also be a > location name that makes sense across all Editions. > > A path that contains "sysimage" conveys to me that this is somehow > only related to image based variants. Something under /usr/var would > at least be an generic, non-confusing path. +1 to that. /usr/lib/sysimage is definitely a non-obvious location for rpmdb, while /usr/var/lib at least suggests it's something akin to /var/lib. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Thu, Jan 13, 2022 at 8:49 AM David Cantrell wrote: > > On Mon, Jan 10, 2022 at 02:53:52PM -0700, Chris Murphy wrote: > >I don't see how /state solves the problem, rather than just > >rearranging the chairs. > > I've seen the rearranging the chairs comment in multiple locations now. If > the location doesn't matter, why can't the RPM db stay in /var/lib/rpm? It's all about consequences, not that it can't stay in /var/lib/rpm. The rpmdb could go in its own subvolume "rpmdb" mounted at /var/lib/rpm, and snapshot it at the same time as subvolume "root" which contains /etc /usr /opt. Each snapshot is a revision. And a way to mount matching revisions is needed if there's more than one snapshot to rollback. e.g. root-x86-64:fedora36.0 root-x86-64:fedora36.1 rpmdb-x86-64:fedora36.0 rpmdb-x86-64:fedora36.1 When booting root-x86-64:fedora36.1 the helper needs to 'mount -o subvol=rpmdb-x86-64:fedora36.1 --uuid=$fsuuid /var/lib/rpm' When booting root-x86-64:fedora36.0, the helper needs to 'mount -o subvol=rpmdb-x86-64:fedora36.0 --uuid=$fsuuid /var/lib/rpm' And for that matter, it could be state-x86-64:fedora36.0 and .1, mounted at /state. The helper could rewrite /etc/fstab, or develop a "discoverable subvolumes" systemd generator that assembles things per a heuristic. https://lists.freedesktop.org/archives/systemd-devel/2021-November/047063.html It's true that this change proposal doesn't go far enough. The issues with /var go beyond /var/lib/rpm. What about /var/lib/selinux? It's owned by the selinux-policy-targeted package. Even though the files may not change often, it probably needs to be snapshot and rolled back with revision matching for /usr and rpmdb. It could be done with a subvolume or another file system with LVM. There might be 6 of these carve outs. Instead of possibly 6+ file systems for LVM thin setups, there could be two: "system" is subject to snapshots and rollbacks, "variable" is not. The same "discoverable subvolumes" systemd-generator idea proposes working with plain directories using the same naming scheme, and would use bind mounts to just reassemble everything from those two file systems onto the FHS layout. Including read-only /usr. This was brought up on devel@ list a year ago and discussed at length, explains the difficulties with the many carve outs approach (open)SUSE has been using, and the various pros and consequences to go about simplifying it. https://github.com/lnussel/lnussel.github.io/blob/fs/_posts/2020-12-16-fslayout.md > These are valid points. My suggestion of /state (or another named top-level > directory...I saw /meta suggested somewhere, maybe LWN...but I kind of don't > want to imply references to Facebook) is on the basis of RPM operating with a > single database on a given system. The idea of multiple RPM databases is > interesting and I think there's value in discussing that, but that would be a > separate item for discussion. > > Right now, a system needs to support installation from the vendor, third party > repos, and local system packages. All with a single RPM database. So I > suggested /state to get that information out of /var but still keep it tied to > the host in question. I don't think /state is a bad idea. Maybe it suffers the same issue as this change proposal, in that it doesn't go far enough? > The /opt tree introduces another wrinkle. It's one that's never really gained > a lot of use in the Linux world, but where it has it's been treated as both a > place where vendors can deliver software and a separate /usr/local. I think > it's reasonable to assume vendor-delivered things in /opt can be thought of as > more independent than what's in /usr, but that's just an assumption. My most > recent views of things found in /opt from third party vendors shows that they > are self-contained trees built with the mindset of "I don't trust what the > system will provide me". I guess the main issue here for snapshots and rollbacks is, would it be ok to put /opt and /usr on the same lifecycle? They get snapshot and rolled back together? Or should /opt be a 3rd party playground and perhaps not even be subject to snapshots and rollbacks, it's entirely managed by rpm only? I don't know the answer to that. But I kinda like the idea of separate /opt with its own rpmdb. That way 'rm -rf /opt/*' is a valid way to reset the 3rd party location without messing up rpmdb because it too is cleaned up. > To move the RPM database in to /usr for the rpm-ostree snapshot and rollback > case would also imply restrictions around what a user can and can't do with > RPM on their system. If that's the case, then I would say rpm should stop > being a general purpose tool for the user and become a backend only tool run > by the OS. Let the users create new third party packaging systems to install > things on their own system. I'm not sure about this. -- Chris Murphy ___ devel mailing list -- devel@lists.fedorapro
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Wed, Jan 12, 2022 at 9:45 AM Chris Murphy wrote: > > Given the choice, I prefer rpm only touches /usr, which includes > /usr/var and /usr/etc. I must say that, of all the bad suggestions in the multiple threads this proposal has spawned, I dislike using "/usr/var/" the least. The path "/usr/lib/sysimage/rpm" does look very out-of-place in non-image-based systems, so *if* we want to move the rpmdb to a place that's consistent across all our Editions, it should also be a location name that makes sense across all Editions. A path that contains "sysimage" conveys to me that this is somehow only related to image based variants. Something under /usr/var would at least be an generic, non-confusing path. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Thu, Jan 13, 2022 at 8:34 AM David Cantrell wrote: > > On Mon, Jan 10, 2022 at 01:24:20PM -0500, Colin Walters wrote: > > > >No, this is not about developers tar'ing up `/usr` by hand. It's about > >cleanly separating who owns what, and what its lifecycle is, which is > >critcially important for both "image based" updates as well as "local client > >side snapshots". Both these approaches end up creating more than one copy of > >certain files. > > I was trying to give an additional example of what people may do with /usr and > the expectations around it. /usr contains data that comes from the > distribution. We drop packages in place and we get files from that. The RPM > database is generated and updated on the target system and represents the > actions of RPM on that system. This is why I categorize the RPM database > differently than the rest of what is in /usr. Does rpm-ostree has the rpmdb in the wrong place? Or is the OSTree model OK because of where rpmdb was created, or how it's delivered, not because of the intrinsic nature of the rpmdb file? > >On what basis are you making this claim "unnecessary and sort of out of > >place"? > > See above. The RPM database contains data generated by RPM on the system in > question, it's not delivered to the user in a package or some other form. It is delivered to the user in some other form on rpm-ostree systems, not generated on the system in question. Does the location or delivery mechanism of the rpmdb alter the appropriateness of /usr as a location? Why does rpmdb's origin act as a material fact in determining where it should be stored rather than its intrinsic nature? I do not think the FHS helps us resolve where rpmdb goes because the FHS's own history of changes shows how often it made the wrong call. It follows reality rather than leading it. By nature it describes a universe. One system. Not many systems, not a multiverse. FHS: "/usr/lib includes object files and libraries. On some systems, it may also include internal binaries that are not intended to be executed directly by users or shell scripts." It is in effect anything that has to do with system function. There's a boat load of man pages, images, source files, in /usr. Clearly I can add to /usr outside of RPM by compiling and installing the kernel from upstream git. Binaries subsequently appear in /usr as a result of that action, but not in rpmdb. Therefore parity between the binaries in /usr and what's reflected in rpmdb is not an argument for whether a thing is appropriate for /usr or not. Nor where rpmdb is built or how it's delivered. 5.8. /var/lib : Variable state information 5.8.1. Purpose "State information is generally used to preserve the condition of an application (or a group of inter-related applications) between invocations and between different instances of the same application. State information should generally remain valid after a reboot, should not be logging output, and should not be spooled data." The rpmdb is most often *invariant*. Or more correctly, its variance is directly associated with some other variance, like a package being added, modified, or removed. It doesn't get modified as a matter of course like a VM image, or http database, or logs. Since the FHS provides no guidance on /state, I have to agree that /state is a better location than /var on the face of it. Chances are /var was never really a very good location for rpmdb in the first place, but it only becomes obvious upon system snapshots creating a multiverse of systems. There isn't a single system on a system with system snapshots. There are now multiple systems of different revisions. And that suggests multiple rpmdb's of different revisions to describe them. Or perhaps a single rpmdb that is snapshot aware, containing information about all system snapshots. So I think we are better off trying to understand the relative consequences of /state versus /usr for rpmdb than appealing to any higher authority (like the FHS), or feelings. I can't act on either the FHS or feelings, they're both unreliable. > >At least from my PoV, the rpmdb is by default read-only (except to > >rpm-ostree) along with the rest of /usr, so you can't just rm -rf it alone. > > Except removing a package would write that change to the rpmdb. Removing a package that contains files in /usr involves writes to /usr regardless of where rpmdb is located, because any modification of /usr means /usr must be read-write. Add, modify or remove. Even our default mount option, relatime, results in writes to /usr every day just by using the system. > >We have years of investment in rpm-ostree in the current design. For > >example, the tooling supports `rpm-ostree db diff` which shows you the delta > >between the current and pending rpmdb. How would this new directory work? > >How would it better solve problems that are today solved with the location in > >/usr? And do you even have a sense of how much work would creating for t
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Tue, Jan 11, 2022 at 11:00:28AM +0200, Panu Matilainen wrote: On 1/10/22 23:53, Chris Murphy wrote: On Mon, Jan 10, 2022 at 9:20 AM David Cantrell wrote: On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr == Summary == 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. [snip] Moving the RPM database to /usr feels incorrect to me, but we should move it to gain the improvements as noted in the feature proposal. Going back to the original discussions on moving rpmdb... Preferred is a new top-level location in /usr, .e.g /usr/sysimage/rpm. Next is "least worst" in /usr/lib/sysimage/rpm http://lists.rpm.org/pipermail/rpm-maint/2017-October/006764.html http://lists.rpm.org/pipermail/rpm-maint/2017-October/006722.html And the convergence was on /usr/lib/sysimage/rpm http://lists.rpm.org/pipermail/rpm-maint/2017-October/006785.html I don't see how /state solves the problem, rather than just rearranging the chairs. The problem with /usr/something is that the rpmdb is not specific to /usr contents at all, and unlike any other content in there, so putting it there just *feels so wrong*. That's what /state or /sysimage or, as we now have, /var supposedly solves. +1 I thought I'd suggested something at / level back then (in https://lists.rpm.org/pipermail/rpm-maint/2017-October/006697.html and/or https://lists.rpm.org/pipermail/rpm-maint/2017-October/006699.html) but seems like memory is failing me :) Maybe I thought it would seem too outrageous to FHS believers to bother. The point was though, that the rpmdb is not at all the only data of this kind and so having a dedicated home makes sense. For many practical purposes it's probably just rearranging the chairs, but a separate top-level directory describing the *system* state seems instinctively *much* more correct solution to it than stuffing it somewhere deep inside a loosely related fs. Also +1 Just FWIW, I would quit my whining about this right there if it went to a new toplevel directory instead because it just *feels* right unlike /usr. Numerous followups have noted the requirement that /usr contain read-only content, that it be shareable across hosts, and similar concepts. While this may or may not doable now like we could in the past, the bigger thing to me is around the understanding of what /usr contains. It is generally understood that /usr contains [most of] the installed system. What I think is a bigger requirement or expection now is that one can tar up /usr and transport it to another system or virtual machine or container and expect that it will _probably_ work maybe with a bit of tinkering. This is a really valuable thing to have for developers. Moving the RPM database to this tree adds a component that is unnecessary and sort of out of place. Should /usr be independently portable? And is that with a version matched /opt, or can there be mix and match revisions of /usr and /opt? If /usr is to be truly portable and have e.g. 'rpm query, verify, remove, reinstall' work as expected, you need the metadata (the database) representing its state to always come along for the ride. Either the database is already in /usr, or you have to make sure /usr and /state are inseparable. If /usr and /state are inseparable, and if rpm can also describe anything in /etc or /var or /opt, then all or part of those directories are also inseparable from /state. And thus /usr. So I think /state doesn't help. For one, /state (or whatever toplevel directory) allows for the fact that there are write-operations to rpmdb that do not touch any external files while maintaining read-only /usr. Such as rpmdb --rebuilddb, or rpm --import. And like mentioned in the original discussion and now here, although the discussion is on rpmdb, it's not the only data of this kind. Indeed. We have an opportunity here to get data that fits this categorization in to a more correct location on the system. rpmdb is a big one, but certainly not the only one. To what degree do rpm and dnf intend to touch locations outside of /usr *and care* about tracking those changes? I don't understand the question. Rpm tracks and cares about all content it knows about equally, regardless of the path. /usr is NOT special in any way to rpm, it's just that most of *distro* content ends up in there but a huge number of packages have content spread across /etc too. Yes, the special semantics around /usr is from the rpm-ostree side and not rpm. I think rpm can't remain static for all time. It either needs to become aware of multiple root trees, and even mix and match top-level directories to create variable roots. And possibly even manage these things. Or it needs to constrain its reach to /usr and /opt. Whether /usr and /opt are tied together, or can be mix and match with t
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Mon, Jan 10, 2022 at 02:53:52PM -0700, Chris Murphy wrote: On Mon, Jan 10, 2022 at 9:20 AM David Cantrell wrote: On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote: >https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr > >== Summary == >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. >[snip] Moving the RPM database to /usr feels incorrect to me, but we should move it to gain the improvements as noted in the feature proposal. Going back to the original discussions on moving rpmdb... Preferred is a new top-level location in /usr, .e.g /usr/sysimage/rpm. Next is "least worst" in /usr/lib/sysimage/rpm http://lists.rpm.org/pipermail/rpm-maint/2017-October/006764.html http://lists.rpm.org/pipermail/rpm-maint/2017-October/006722.html And the convergence was on /usr/lib/sysimage/rpm http://lists.rpm.org/pipermail/rpm-maint/2017-October/006785.html I don't see how /state solves the problem, rather than just rearranging the chairs. I've seen the rearranging the chairs comment in multiple locations now. If the location doesn't matter, why can't the RPM db stay in /var/lib/rpm? Numerous followups have noted the requirement that /usr contain read-only content, that it be shareable across hosts, and similar concepts. While this may or may not doable now like we could in the past, the bigger thing to me is around the understanding of what /usr contains. It is generally understood that /usr contains [most of] the installed system. What I think is a bigger requirement or expection now is that one can tar up /usr and transport it to another system or virtual machine or container and expect that it will _probably_ work maybe with a bit of tinkering. This is a really valuable thing to have for developers. Moving the RPM database to this tree adds a component that is unnecessary and sort of out of place. Should /usr be independently portable? And is that with a version matched /opt, or can there be mix and match revisions of /usr and /opt? If /usr is to be truly portable and have e.g. 'rpm query, verify, remove, reinstall' work as expected, you need the metadata (the database) representing its state to always come along for the ride. Either the database is already in /usr, or you have to make sure /usr and /state are inseparable. If /usr and /state are inseparable, and if rpm can also describe anything in /etc or /var or /opt, then all or part of those directories are also inseparable from /state. And thus /usr. So I think /state doesn't help. To what degree do rpm and dnf intend to touch locations outside of /usr *and care* about tracking those changes? I think rpm can't remain static for all time. It either needs to become aware of multiple root trees, and even mix and match top-level directories to create variable roots. And possibly even manage these things. Or it needs to constrain its reach to /usr and /opt. Whether /usr and /opt are tied together, or can be mix and match with their own rpmdb's, I have no strong opinion on. These are valid points. My suggestion of /state (or another named top-level directory...I saw /meta suggested somewhere, maybe LWN...but I kind of don't want to imply references to Facebook) is on the basis of RPM operating with a single database on a given system. The idea of multiple RPM databases is interesting and I think there's value in discussing that, but that would be a separate item for discussion. Right now, a system needs to support installation from the vendor, third party repos, and local system packages. All with a single RPM database. So I suggested /state to get that information out of /var but still keep it tied to the host in question. The /opt tree introduces another wrinkle. It's one that's never really gained a lot of use in the Linux world, but where it has it's been treated as both a place where vendors can deliver software and a separate /usr/local. I think it's reasonable to assume vendor-delivered things in /opt can be thought of as more independent than what's in /usr, but that's just an assumption. My most recent views of things found in /opt from third party vendors shows that they are self-contained trees built with the mindset of "I don't trust what the system will provide me". To move the RPM database in to /usr for the rpm-ostree snapshot and rollback case would also imply restrictions around what a user can and can't do with RPM on their system. If that's the case, then I would say rpm should stop being a general purpose tool for the user and become a backend only tool run by the OS. Let the users create new third party packaging systems to install things on their own system. -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedor
Re: New top-level dir: /state [
On Mon, Jan 10, 2022 at 12:55:03PM -0500, Stephen Gallagher wrote: On Mon, Jan 10, 2022 at 12:30 PM Frank Ch. Eigler wrote: David Cantrell writes: > Reading comments and talking to people, the long standing understanding of > /var is still "that's stuff you can rm -rf and the system will still work > fine". Technically you could remove the RPM database and the system still > function [...] Considering that many other valuable mutable state are put under /var are put there, databases, container images, etc. etc. etc, this understanding cannot be correct. We could just leave /var alone. # sudo du -s /var/lib/* I *think* what David is suggesting here is that while databases and container images are indeed changeable data that lives in /var (and are likely VERY important to the user), they are not critical to the functioning of the operating system itself. The OS will still boot and you can still log in[1] if /var is wiped clean, though the system will probably not be doing anything useful at this point. Whereas if the RPM database is damaged or removed, a core function of the operating system (installation and updates) will no longer work. Yes, that is what I was suggesting. I think there is definite value in considering adding a new location (though it need not be at the top-level) for data like this. I'll note that the FHS states the following[2] in regards to /var: "Everything that once went into /usr that is written to during system operation (as opposed to installation and software maintenance) must be in /var." This exception seems to me to be clearly implying that "installation and software maintenance" do not need to be in /var (and as CoreOS has shown, there's value to keeping it somewhere else). A further quote from the same section of the FHS suggests the use of /usr/var, which is a location we are not currently using in the Fedora Project, but seems like it would fit the requirements for both CoreOS and traditional RPM Fedora. This same hierarchy could be used for /var/log and /var/lib/libvirt/images as well. The FHS reasoning ties back to the read-only /usr goal and sharing /usr among multiple systems, so you wouldn't want host-specifics written in there. I see that still applying to image-based management of /usr, honestly. -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Mon, Jan 10, 2022 at 01:24:20PM -0500, Colin Walters wrote: On Mon, Jan 10, 2022, at 11:19 AM, David Cantrell wrote: On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr == Summary == 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. [snip] Moving the RPM database to /usr feels incorrect to me, but we should move it to gain the improvements as noted in the feature proposal. Numerous followups have noted the requirement that /usr contain read-only content, that it be shareable across hosts, and similar concepts. While this may or may not doable now like we could in the past, the bigger thing to me is around the understanding of what /usr contains. It is generally understood that /usr contains [most of] the installed system. What I think is a bigger requirement or expection now is that one can tar up /usr and transport it to another system or virtual machine or container and expect that it will _probably_ work maybe with a bit of tinkering. This is a really valuable thing to have for developers. No, this is not about developers tar'ing up `/usr` by hand. It's about cleanly separating who owns what, and what its lifecycle is, which is critcially important for both "image based" updates as well as "local client side snapshots". Both these approaches end up creating more than one copy of certain files. I was trying to give an additional example of what people may do with /usr and the expectations around it. /usr contains data that comes from the distribution. We drop packages in place and we get files from that. The RPM database is generated and updated on the target system and represents the actions of RPM on that system. This is why I categorize the RPM database differently than the rest of what is in /usr. See - https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/ - http://lists.rpm.org/pipermail/rpm-maint/2021-December/018770.html Moving the RPM database to this tree adds a component that is unnecessary and sort of out of place. I struggle to how to even respond to this. Multiple independent groups who *actually work* on image based updates and/or client side snapshots all generally agree that the rpmdb should be in /usr. That's where this Change came in. On what basis are you making this claim "unnecessary and sort of out of place"? See above. The RPM database contains data generated by RPM on the system in question, it's not delivered to the user in a package or some other form. The change proposal is about moving the RPM database to /usr. I am offering my comments on why I think /usr is the incorrect location for this data. "OK, but you can do tar -X" The tar example was simply that, an example. I feel the categorization of system data is more important here. Panu brought this up on the referenced RPM mailing list thread years ago. The original /var location for the RPM database was fine, but we're at a point where we kind of have multiple categories of things historically found in /var. Reading comments and talking to people, the long standing understanding of /var is still "that's stuff you can rm -rf and the system will still work fine". Yes, we call this "factory reset". https://github.com/coreos/fedora-coreos-tracker/issues/399 I am not sure where the terminology came from, but it is widely used when talking about e.g. mobile phones today. Technically you could remove the RPM database and the system still function, but arguably would still be broken since you really want the RPM database. This use case of removing the RPM database and still having a functioning system is really only useful for data recovery scenarios. You're ultimately going to reinstall. Probably. At least from my PoV, the rpmdb is by default read-only (except to rpm-ostree) along with the rest of /usr, so you can't just rm -rf it alone. Except removing a package would write that change to the rpmdb. So maybe the question is more "what is the correct location for data like the RPM database?" First, how is that data different from the rest of /var? It is host-specific, No. An image based updates model (both ostree and container images) ships a pristine copy that is bit-for-bit the same on every system. Container runtimes tend to make it mutable by default of course, but that doesn't change the fact that it's not by default host specific. We have other Fedora editions besides rpm-ostree. This change affects everyone. I would like to see Fedora introduce a new top-level directory called: /state We have years of investment in rpm-ostree in the current design. For example, the tooling supports `rpm-ostree db diff` which shows you the delta between the current and pending rpmdb. How would this new directory work? How would it better solve problems
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Thu, Jan 13, 2022, at 7:52 AM, Vít Ondruch wrote: > Actually, shouldn't rpm-ostree carry around some copy of the RPM > database, which would describe the state of /usr and once the update is > successful (or snapshot active?), merge it into the main system RPM > database? Apparently, something like this is already happening e.g. for > /etc content if I understand it correctly. Or this is the direction in > which the /boot will be handled eventually. Or possibly it could be just > some linked (possibly just read only) database. I think you are confusing/conflating image based updates and client side snapshots (and relatedly, client side offline updates, which is what https://github.com/OpenSUSE/transactional-update). They are related, but different. It's important to emphasize that rpm-ostree systems are by default, *image based*. For example, every single Fedora CoreOS system running the latest "stable" commit has *bit for bit identical /usr*, including the RPM database in /usr/share/rpm. All SELinux labeling was computed server side. All %post scripts were run on the build server. We perform integration testing on that image before it ever hits any user's disk. See https://github.com/coreos/fedora-coreos-tracker/issues/1066 for example. (This integration testing aspect is not true of Silverblue or IoT, because they just ship what bodhi ships, which is its own big problem) If one chooses to engage client side layering (or overrides), rpm-ostree will (each time an upgrade or change is performed) indeed regenerate the rpm database using the "pristine" base image's version of the rpmdb. What you are talking about seems more related to client side snapshots and/or client side offline updates. So in your phrasing above I'd say something more like "proposed dnf/snapper tooling" or so, and not rpm-ostree which works in a different way. > IOW, imagine, that we still keep the system read/write RPM database in > /var and we teach RPM to use additional database(s). So RPM would know > that there might be some additional database e.g. in /usr/var/ ... The > system database would not know nothing about content of /usr, but once > /usr was mounted, `rpm -q` would provide the information from the linked > RPM database. I am having trouble understanding what you are thinking here. If you are interested in this, I'd recommend taking some time trying out an existing system that is doing some of these things; either an OpenSUSE transactional-update system or an rpm-ostree system for example. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
Dne 12. 01. 22 v 22:05 Chris Murphy napsal(a): On Wed, Jan 12, 2022 at 2:04 AM Panu Matilainen wrote: On 1/12/22 10:45, Chris Murphy wrote: On Tue, Jan 11, 2022 at 2:00 AM Panu Matilainen wrote: For many practical purposes it's probably just rearranging the chairs, but a separate top-level directory describing the *system* state seems instinctively *much* more correct solution to it than stuffing it somewhere deep inside a loosely related fs. If rpm is constrained to /usr, then its database can properly be somewhere in /usr If rpm is unconstrained, with transactions touching any of /usr /var /opt /etc, the resulting paradigm is inherently complicated, and an additional top-level directory doesn't help make it less complicated. WTF is this talk about constraining? There's no such constraint in rpm, and never will. I'm not talking about changing the nature of the beast. I'm talking about how it's used as a tool in a distribution with a lot of other requirements and tradeoffs. Expanding rpm is also a valid path. We have an example "DNF snapper plug-in" that demonstrates at least DNF *could* get into the business of managing snapshots and rollbacks, if it wants that responsibility, if it's helpful and worth the effort, and if the resources exist to do it. That's an interesting discussion. And Fedora packages are not constrained there either, a vast percentage places stuff in /etc, touches directory tree in /var and then there's /boot and the software collections and third party software. /boot might need its own manager(s). I'm strongly leaning toward bootupd and fwupd being the only things that touch /boot and everything else is proscribed. /boot is a small but hot mess right now. RPM, grub, grubby, dracut, all can touch /boot and in the Boot Loader Spec context there's multiple OS's sharing /boot. About the only thing I like better is linux as the bootloader, e.g. Linux Boot, so we have real device and file system drivers. Anything that manages /boot needs to needs understand snapshots, and which kernel+initramfs can boot which snapshots. Either top-level directories have their own databases, so rpm knows what's in them even if one is rolled back but not another; or there's one database to describe all of these top-level directories which then need to share a single (sub)volume so they're all snapshot and rolled back together. Either way, there's additionally a need for carve outs for things that shouldn't be rolled back. Erm. Packages don't live conveniently inside a single top level tree, they can't be split up that way. Right. I view this as a criticism, not a benefit though. Neither rpm nor the FHS are organizing things in a way that helps us do rollbacks. They're impediments we keep having to take other shortcuts and workarounds to achieve that goal, and as yet they still have too many shortcomings. It really isn't to be underestimated the importance of multiple independent parties coming to the same kinds of conclusions. Given the choice, I prefer rpm only touches /usr, which includes /usr/var and /usr/etc. But if left unconstrained, having databases inside the directories they describe is more reliable than treating the database as a sidecar file that can much more easily become disconnected with one or more top-level directories it ostensibly describes the contents of. Here seems to be another SMALL undocumented dependency of this change: completing the /usrmove thing to cover the whole world including /opt, /etc, /var, and presumably /boot as well because packages put stuff in it. Rpm wont care if you want to move content from /etc to /usr/etc and ditto for /var, /opt and /boot which is also used by packages, ie to complete to complete the great /usrmove thing started a decade ago. But that's quite a hidden agenda in this change if you ask me. This change proposal is narrow in scope. It imagines a future snapshot+rollback regime of some kind, but isn't depending on any particular file system or way of achieving it. I personally like the transactional updates approach. I like what rpm-ostree is doing, updating the system root out of band rather than updating the currently running system. Actually, shouldn't rpm-ostree carry around some copy of the RPM database, which would describe the state of /usr and once the update is successful (or snapshot active?), merge it into the main system RPM database? Apparently, something like this is already happening e.g. for /etc content if I understand it correctly. Or this is the direction in which the /boot will be handled eventually. Or possibly it could be just some linked (possibly just read only) database. IOW, imagine, that we still keep the system read/write RPM database in /var and we teach RPM to use additional database(s). So RPM would know that there might be some additional database e.g. in /usr/var/ ... The system database would not know nothing about content of /usr, but once /usr was mounted, `rpm -q` wou
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Wed, Jan 12, 2022 at 2:57 PM Neal Gompa wrote: > > On Wed, Jan 12, 2022 at 3:54 AM Chris Murphy wrote: > > > > On Wed, Jan 12, 2022 at 1:36 AM Panu Matilainen wrote: > > > > > > > So by moving the rpmdb to /usr, it's basically saying that `rpm > > > > --import` should change. > > > > > > This doesn't seem to be documented as a dependency of this move... > > > > > > > Added. > > https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr#Dependencies > > > > No. This is nonsense. In current Fedora, this doesn't matter. In a > hypothetical future model of a transactional system, we'd want to move > repo configs and gpg key files from /etc to /usr at the same time. > > Right now, this is out of scope because the DNF team is not ready for that > work. Ahh yeah fair enough. There are further discussions before we actually get to snapshot and rollbacks, not least of which is things like 'dnf history' can't show you an accurate history if there's been an external (filesystem) rollback of the system root that does not rollback /var/lib/dnf. Ideally we'd never have to rollback anything in /var, but possibly with an option for selective restore. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Wed, Jan 12, 2022 at 3:54 AM Chris Murphy wrote: > > On Wed, Jan 12, 2022 at 1:36 AM Panu Matilainen wrote: > > > > > So by moving the rpmdb to /usr, it's basically saying that `rpm --import` > > > should change. > > > > This doesn't seem to be documented as a dependency of this move... > > > > Added. > https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr#Dependencies > No. This is nonsense. In current Fedora, this doesn't matter. In a hypothetical future model of a transactional system, we'd want to move repo configs and gpg key files from /etc to /usr at the same time. Right now, this is out of scope because the DNF team is not ready for that work. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Wed, Jan 12, 2022 at 2:04 AM Panu Matilainen wrote: > > On 1/12/22 10:45, Chris Murphy wrote: > > On Tue, Jan 11, 2022 at 2:00 AM Panu Matilainen wrote: > >> For many practical purposes it's probably just rearranging the chairs, > >> but a separate top-level directory describing the *system* state seems > >> instinctively *much* more correct solution to it than stuffing it > >> somewhere deep inside a loosely related fs. > > > > If rpm is constrained to /usr, then its database can properly be > > somewhere in /usr > > > > If rpm is unconstrained, with transactions touching any of /usr /var > > /opt /etc, the resulting paradigm is inherently complicated, and an > > additional top-level directory doesn't help make it less complicated. > > WTF is this talk about constraining? There's no such constraint in rpm, > and never will. I'm not talking about changing the nature of the beast. I'm talking about how it's used as a tool in a distribution with a lot of other requirements and tradeoffs. Expanding rpm is also a valid path. We have an example "DNF snapper plug-in" that demonstrates at least DNF *could* get into the business of managing snapshots and rollbacks, if it wants that responsibility, if it's helpful and worth the effort, and if the resources exist to do it. That's an interesting discussion. > And Fedora packages are not constrained there either, a > vast percentage places stuff in /etc, touches directory tree in /var and > then there's /boot and the software collections and third party software. /boot might need its own manager(s). I'm strongly leaning toward bootupd and fwupd being the only things that touch /boot and everything else is proscribed. /boot is a small but hot mess right now. RPM, grub, grubby, dracut, all can touch /boot and in the Boot Loader Spec context there's multiple OS's sharing /boot. About the only thing I like better is linux as the bootloader, e.g. Linux Boot, so we have real device and file system drivers. Anything that manages /boot needs to needs understand snapshots, and which kernel+initramfs can boot which snapshots. > > Either top-level directories have their own databases, so rpm knows > > what's in them even if one is rolled back but not another; or there's > > one database to describe all of these top-level directories which then > > need to share a single (sub)volume so they're all snapshot and rolled > > back together. Either way, there's additionally a need for carve outs > > for things that shouldn't be rolled back. > > Erm. Packages don't live conveniently inside a single top level tree, > they can't be split up that way. Right. I view this as a criticism, not a benefit though. Neither rpm nor the FHS are organizing things in a way that helps us do rollbacks. They're impediments we keep having to take other shortcuts and workarounds to achieve that goal, and as yet they still have too many shortcomings. It really isn't to be underestimated the importance of multiple independent parties coming to the same kinds of conclusions. > > Given the choice, I prefer rpm only touches /usr, which includes > > /usr/var and /usr/etc. > > > > But if left unconstrained, having databases inside the directories > > they describe is more reliable than treating the database as a sidecar > > file that can much more easily become disconnected with one or more > > top-level directories it ostensibly describes the contents of. > > Here seems to be another SMALL undocumented dependency of this change: > completing the /usrmove thing to cover the whole world including /opt, > /etc, /var, and presumably /boot as well because packages put stuff in it. > > Rpm wont care if you want to move content from /etc to /usr/etc and > ditto for /var, /opt and /boot which is also used by packages, ie to > complete to complete the great /usrmove thing started a decade ago. But > that's quite a hidden agenda in this change if you ask me. This change proposal is narrow in scope. It imagines a future snapshot+rollback regime of some kind, but isn't depending on any particular file system or way of achieving it. I personally like the transactional updates approach. I like what rpm-ostree is doing, updating the system root out of band rather than updating the currently running system. I like the idea these updates can happen in a container, if they fail for any reason we just remove that bad tree - it's a completely disposable thing until it successfully updates and maybe we can even automate some simple tests (it gets to X milestone in the boot process) before we activate it as the current root. I like the idea of users being able to follow the trail of breadcrumbs of how systems boot. My strong bias from many years in Fedora QA is we deal every cycle with boot/startup failure in some form or another, and the less obscure less fragile more self-describing and standard that process can be, the easier it is to avoid, find and fix problems. We also know that (open)SUSE has proven a workin
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Wed, Jan 12, 2022, at 4:04 AM, Panu Matilainen wrote: > > Here seems to be another SMALL undocumented dependency of this change: > completing the /usrmove thing to cover the whole world including /opt, > /etc, /var, and presumably /boot as well because packages put stuff in it. There are very few packages that put things in /boot. For example, fwupd used to be in that set, but moved into a "self updater" model where the binary goes in /usr, and then it copies itself into the ESP instead of having yum/rpm do it. Now, rpm-ostree also does this with /boot: https://github.com/coreos/rpm-ostree/blob/210bf148342a9545c9841ae6d8403354ce49b672/src/libpriv/rpmostree-util.cxx#L134 And then we have a sister project https://github.com/coreos/bootupd/ that is only shipped in FCOS today (but would make sense to use on everything that uses rpm-ostree) which is scoped explicitly to only handle stuff on the ESP (and eventually, stuff like grub on the MBR and other architectures too). Correct handling of /boot is obviously essential for transactional updates; ostree is entirely designed around a "strong binding" of (kernel, userspace) pairs. Handling kernels in /boot for "client side snapshots" is something most projects in this space do out of band, as far as I've seen. Again, it's really that 90% of the data in the rpmdb is for /usr. We recently changed the kernel RPM to stick the kernel binary in /usr/lib/modules/$kver and only *copy* it from there to strengthen this model. And this move is pushing things farther along in that direction. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On 1/12/22 10:45, Chris Murphy wrote: On Tue, Jan 11, 2022 at 2:00 AM Panu Matilainen wrote: The problem with /usr/something is that the rpmdb is not specific to /usr contents at all, and unlike any other content in there, so putting it there just *feels so wrong*. That's what /state or /sysimage or, as we now have, /var supposedly solves. I thought I'd suggested something at / level back then (in https://lists.rpm.org/pipermail/rpm-maint/2017-October/006697.html and/or https://lists.rpm.org/pipermail/rpm-maint/2017-October/006699.html) but seems like memory is failing me :) Maybe I thought it would seem too outrageous to FHS believers to bother. The point was though, that the rpmdb is not at all the only data of this kind and so having a dedicated home makes sense. For many practical purposes it's probably just rearranging the chairs, but a separate top-level directory describing the *system* state seems instinctively *much* more correct solution to it than stuffing it somewhere deep inside a loosely related fs. If rpm is constrained to /usr, then its database can properly be somewhere in /usr If rpm is unconstrained, with transactions touching any of /usr /var /opt /etc, the resulting paradigm is inherently complicated, and an additional top-level directory doesn't help make it less complicated. WTF is this talk about constraining? There's no such constraint in rpm, and never will. And Fedora packages are not constrained there either, a vast percentage places stuff in /etc, touches directory tree in /var and then there's /boot and the software collections and third party software. Either top-level directories have their own databases, so rpm knows what's in them even if one is rolled back but not another; or there's one database to describe all of these top-level directories which then need to share a single (sub)volume so they're all snapshot and rolled back together. Either way, there's additionally a need for carve outs for things that shouldn't be rolled back. Erm. Packages don't live conveniently inside a single top level tree, they can't be split up that way. Many if not most span at least /etc and /usr, and /usr may be further split into separate mounts (eg /usr/local or /usr/share). And many things which install to /opt also place things into /usr for desktop integration. We have an example of the latter. (open)SUSE's current layout. There's a 10 line /etc/fstab, 9 of which are various Btrfs subvolumes to achieve the necessary carve out. It's sufficiently complex that the direction they're looking to go in is one in which rpm's only touch /usr. There's /usr/etc for read-only systemd defaults. And local customizations go in /etc. Much like rpm-ostree. Projects within two rpm-based distros independently came to realize that unconstrained rpm is difficult. Where rpm-ostree decided to do the hard work of actually becoming aware of the reality there's multiple system roots. I don't understand the question. Rpm tracks and cares about all content it knows about equally, regardless of the path. /usr is NOT special in any way to rpm, it's just that most of *distro* content ends up in there but a huge number of packages have content spread across /etc too. I think rpm can't remain static for all time. It either needs to become aware of multiple root trees, and even mix and match top-level directories to create variable roots. And possibly even manage these things. Or it needs to constrain its reach to /usr and /opt. Whether /usr and /opt are tied together, or can be mix and match with their own rpmdb's, I have no strong opinion on. Oh, multiple rpmdbs. It's a while since that last turned up. It gets tossed around as a solution but to me it looks like it brings more problems than it solves. Given the choice, I prefer rpm only touches /usr, which includes /usr/var and /usr/etc. But if left unconstrained, having databases inside the directories they describe is more reliable than treating the database as a sidecar file that can much more easily become disconnected with one or more top-level directories it ostensibly describes the contents of. Here seems to be another SMALL undocumented dependency of this change: completing the /usrmove thing to cover the whole world including /opt, /etc, /var, and presumably /boot as well because packages put stuff in it. Rpm wont care if you want to move content from /etc to /usr/etc and ditto for /var, /opt and /boot which is also used by packages, ie to complete to complete the great /usrmove thing started a decade ago. But that's quite a hidden agenda in this change if you ask me. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines L
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Wed, Jan 12, 2022 at 1:36 AM Panu Matilainen wrote: > > > So by moving the rpmdb to /usr, it's basically saying that `rpm --import` > > should change. > > This doesn't seem to be documented as a dependency of this move... > Added. https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr#Dependencies -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Tue, Jan 11, 2022 at 2:00 AM Panu Matilainen wrote: > The problem with /usr/something is that the rpmdb is not specific to > /usr contents at all, and unlike any other content in there, so putting > it there just *feels so wrong*. That's what /state or /sysimage or, as > we now have, /var supposedly solves. > > I thought I'd suggested something at / level back then (in > https://lists.rpm.org/pipermail/rpm-maint/2017-October/006697.html > and/or > https://lists.rpm.org/pipermail/rpm-maint/2017-October/006699.html) but > seems like memory is failing me :) Maybe I thought it would seem too > outrageous to FHS believers to bother. > > The point was though, that the rpmdb is not at all the only data of this > kind and so having a dedicated home makes sense. > > For many practical purposes it's probably just rearranging the chairs, > but a separate top-level directory describing the *system* state seems > instinctively *much* more correct solution to it than stuffing it > somewhere deep inside a loosely related fs. If rpm is constrained to /usr, then its database can properly be somewhere in /usr If rpm is unconstrained, with transactions touching any of /usr /var /opt /etc, the resulting paradigm is inherently complicated, and an additional top-level directory doesn't help make it less complicated. Either top-level directories have their own databases, so rpm knows what's in them even if one is rolled back but not another; or there's one database to describe all of these top-level directories which then need to share a single (sub)volume so they're all snapshot and rolled back together. Either way, there's additionally a need for carve outs for things that shouldn't be rolled back. We have an example of the latter. (open)SUSE's current layout. There's a 10 line /etc/fstab, 9 of which are various Btrfs subvolumes to achieve the necessary carve out. It's sufficiently complex that the direction they're looking to go in is one in which rpm's only touch /usr. There's /usr/etc for read-only systemd defaults. And local customizations go in /etc. Much like rpm-ostree. Projects within two rpm-based distros independently came to realize that unconstrained rpm is difficult. Where rpm-ostree decided to do the hard work of actually becoming aware of the reality there's multiple system roots. > I don't understand the question. Rpm tracks and cares about all content > it knows about equally, regardless of the path. /usr is NOT special in > any way to rpm, it's just that most of *distro* content ends up in there > but a huge number of packages have content spread across /etc too. > > > I think rpm can't remain > > static for all time. It either needs to become aware of multiple root > > trees, and even mix and match top-level directories to create variable > > roots. And possibly even manage these things. Or it needs to constrain > > its reach to /usr and /opt. Whether /usr and /opt are tied together, > > or can be mix and match with their own rpmdb's, I have no strong > > opinion on. > > Oh, multiple rpmdbs. It's a while since that last turned up. It gets > tossed around as a solution but to me it looks like it brings more > problems than it solves. Given the choice, I prefer rpm only touches /usr, which includes /usr/var and /usr/etc. But if left unconstrained, having databases inside the directories they describe is more reliable than treating the database as a sidecar file that can much more easily become disconnected with one or more top-level directories it ostensibly describes the contents of. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On 1/11/22 17:18, Colin Walters wrote: On Tue, Jan 11, 2022, at 4:00 AM, Panu Matilainen wrote: The point was though, that the rpmdb is not at all the only data of this kind and so having a dedicated home makes sense. You mentioned dnf/yum/PackageKit data; there's two kinds of that. One is e.g. /var/cache/dnf which does *not* move. It's just a cache. (Now there is this whole other very interesting thread around "why don't we include a cache of the rpm-md inside e.g. ostree or container images? And the reason why not is we don't want to have to respin all images every time a package not in the image changes) dnf does have its own outside-of-rpm state database in /var/lib/dnf which is closer to this. The situation with that is messier. AIUI this proposal so far is not calling for moving this. Where it lives and how it's versioned has strong implications for the people who want to support snapshot/rollback. But it's not relevant for rpm-ostree, which does not use this part of libdnf. We maintain our own little "state file" - for lots more detail on this, see https://github.com/coreos/rpm-ostree/issues/2326 (And it's important to note that rpm-ostree's origin file has almost nothing *unless* one explicitly engages client-side layering/overrides) For one, /state (or whatever toplevel directory) allows for the fact that there are write-operations to rpmdb that do not touch any external files while maintaining read-only /usr. Such as rpmdb --rebuilddb, `rpmdb --rebuilddb` is basically about supporting switching from e.g. bdb to sqlite, right? On the rpm-ostree side at least, the default format comes from the base image; there's no reason to directly support `rpmdb --rebuilddb` as something any normal user or admin would need. No, it's a database maintenance/repair operation. Converting between formats is merely a convenient side-effect. or rpm --import. OK yes, this (along with rpms that install into /opt as you mentioned) are I think the biggest examples of "rpmdb has stuff not about /usr". rpm --import actually encapsulates really well all the problems and benefits with everything we're trying to do. I have a big related blurb here https://github.com/rpm-software-management/libdnf/issues/43 But as I understand it, the creation of /etc/pki/rpm-gpg was at least partially motivated by the fact that in the traditional RPM model, the fact that GPG keys are stored in the rpmdb meant there was no way to update them "in band" of a default rpm operation. Today Fedora ships these GPG keys as an RPM which hence contain files, and when you type `yum upgrade` (or rpm-ostree upgrade) you get updates to those files, the same as other files. Now, as noted in the issue PackageKit (whose code was the precursor to libdnf, which has the code that rpm-ostree uses but AFAIK still not current dnf which has this logic in Python) auto-imports all of them. I am not completely sure how updating the rpmdb with new e.g. Fedora GPG key works. It might be part of system-upgrade or something? And then this all relates to a higher level goal we have with "image based updates", which is avoiding (or minimizing as much as possible) per-system hysteresis or "unmanaged state", particularly opaque (hard to see/diagnose/inspect) state. This set of trusted GPG keys stored in the rpmdb is both. The set of keys will just keep growing across in-place upgrades, depending on the initial Fedora version installed. And wh And this is security-relevant state, it's the set of trusted keys for RPM. Now, I am sure a number of sysadmins do understand that the rpmdb contains GPG keys. I'd bet a whole lot don't. I definitely think that it's confusing to have both /etc/pki/rpm-gpg *and* keys stored in the rpmdb. Of the two, I think the former - i.e. text files one can edit with standard tools - is much easier to understand and work with. It's also already in a place that is designed for users to edit in `/etc`. So by moving the rpmdb to /usr, it's basically saying that `rpm --import` should change. This doesn't seem to be documented as a dependency of this move... That said, this design could also clearly use some "systemd style" config model. ostree already supports /usr/share/ostree/trusted.gpg.d which is designed for keys shipped by the OS vendor. But, what's really tricky about this is we want to support in-place updates from previous versions (i.e. at least N-1), but hopefully not too old versions. Well, this is leading to a tangent so I'll cut off this sub-thread. The TL;DR for me is: I think everyone agrees that moving the rpmdb as it is today to /usr is not 100% a perfect fit. But it's a ~90% fit - almost all the raw data is just headers which are clearly immutable data generated elsewhere. And by making this change, we're basically saying we'll fix the remaining 10% of cases. Note for the people who are trying to do "client side snapshot/rollback" (i.e.
Re: New top-level dir: /state [
On Tue, Jan 11, 2022 at 6:56 AM Stephen Gallagher wrote: > > On Mon, Jan 10, 2022 at 5:39 PM Chris Murphy wrote: > > > > On Mon, Jan 10, 2022 at 10:55 AM Stephen Gallagher > > wrote: > > > > > A further quote from the same section of the FHS suggests the use of > > > /usr/var, which is a location we are not currently using in the Fedora > > > Project, but seems like it would fit the requirements for both CoreOS > > > and traditional RPM Fedora. This same hierarchy could be used for > > > /var/log and /var/lib/libvirt/images as well. > > > > This is a nice fit > > /var/lib/rpm -> /usr/var/lib/rpm > > > > But it's an ask directed at those who have already implemented this > > change, if it's compelling enough for them to change again. > > Sure, but my reasoning is that such an adaptation could be useful for > multiple cases, not just the rpmdb case. The multiple cases is exactly what resulted in convergence on /usr/lib/sysimage, ergo /usr/lib/sysimage/rpm /usr/lib/sysimage/dpkg /usr/lib/sysimage/pacman /usr/lib/sysimage/dnf -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Tue, Jan 11, 2022, at 4:00 AM, Panu Matilainen wrote: > The point was though, that the rpmdb is not at all the only data of this > kind and so having a dedicated home makes sense. You mentioned dnf/yum/PackageKit data; there's two kinds of that. One is e.g. /var/cache/dnf which does *not* move. It's just a cache. (Now there is this whole other very interesting thread around "why don't we include a cache of the rpm-md inside e.g. ostree or container images? And the reason why not is we don't want to have to respin all images every time a package not in the image changes) dnf does have its own outside-of-rpm state database in /var/lib/dnf which is closer to this. The situation with that is messier. AIUI this proposal so far is not calling for moving this. Where it lives and how it's versioned has strong implications for the people who want to support snapshot/rollback. But it's not relevant for rpm-ostree, which does not use this part of libdnf. We maintain our own little "state file" - for lots more detail on this, see https://github.com/coreos/rpm-ostree/issues/2326 (And it's important to note that rpm-ostree's origin file has almost nothing *unless* one explicitly engages client-side layering/overrides) > For one, /state (or whatever toplevel directory) allows for the fact > that there are write-operations to rpmdb that do not touch any external > files while maintaining read-only /usr. Such as rpmdb --rebuilddb, `rpmdb --rebuilddb` is basically about supporting switching from e.g. bdb to sqlite, right? On the rpm-ostree side at least, the default format comes from the base image; there's no reason to directly support `rpmdb --rebuilddb` as something any normal user or admin would need. > or rpm --import. OK yes, this (along with rpms that install into /opt as you mentioned) are I think the biggest examples of "rpmdb has stuff not about /usr". rpm --import actually encapsulates really well all the problems and benefits with everything we're trying to do. I have a big related blurb here https://github.com/rpm-software-management/libdnf/issues/43 But as I understand it, the creation of /etc/pki/rpm-gpg was at least partially motivated by the fact that in the traditional RPM model, the fact that GPG keys are stored in the rpmdb meant there was no way to update them "in band" of a default rpm operation. Today Fedora ships these GPG keys as an RPM which hence contain files, and when you type `yum upgrade` (or rpm-ostree upgrade) you get updates to those files, the same as other files. Now, as noted in the issue PackageKit (whose code was the precursor to libdnf, which has the code that rpm-ostree uses but AFAIK still not current dnf which has this logic in Python) auto-imports all of them. I am not completely sure how updating the rpmdb with new e.g. Fedora GPG key works. It might be part of system-upgrade or something? And then this all relates to a higher level goal we have with "image based updates", which is avoiding (or minimizing as much as possible) per-system hysteresis or "unmanaged state", particularly opaque (hard to see/diagnose/inspect) state. This set of trusted GPG keys stored in the rpmdb is both. The set of keys will just keep growing across in-place upgrades, depending on the initial Fedora version installed. And wh And this is security-relevant state, it's the set of trusted keys for RPM. Now, I am sure a number of sysadmins do understand that the rpmdb contains GPG keys. I'd bet a whole lot don't. I definitely think that it's confusing to have both /etc/pki/rpm-gpg *and* keys stored in the rpmdb. Of the two, I think the former - i.e. text files one can edit with standard tools - is much easier to understand and work with. It's also already in a place that is designed for users to edit in `/etc`. So by moving the rpmdb to /usr, it's basically saying that `rpm --import` should change. That said, this design could also clearly use some "systemd style" config model. ostree already supports /usr/share/ostree/trusted.gpg.d which is designed for keys shipped by the OS vendor. But, what's really tricky about this is we want to support in-place updates from previous versions (i.e. at least N-1), but hopefully not too old versions. Well, this is leading to a tangent so I'll cut off this sub-thread. The TL;DR for me is: I think everyone agrees that moving the rpmdb as it is today to /usr is not 100% a perfect fit. But it's a ~90% fit - almost all the raw data is just headers which are clearly immutable data generated elsewhere. And by making this change, we're basically saying we'll fix the remaining 10% of cases. Note for the people who are trying to do "client side snapshot/rollback" (i.e. the people whose names are attached to the Change), the rpmdb is still mutable by default. And I think their idea is is that by doing a "snapshot, then upgrade in place via traditional rpm/yum methods" approac
Re: New top-level dir: /state [
On Mon, Jan 10, 2022 at 5:39 PM Chris Murphy wrote: > > On Mon, Jan 10, 2022 at 10:55 AM Stephen Gallagher > wrote: > > > A further quote from the same section of the FHS suggests the use of > > /usr/var, which is a location we are not currently using in the Fedora > > Project, but seems like it would fit the requirements for both CoreOS > > and traditional RPM Fedora. This same hierarchy could be used for > > /var/log and /var/lib/libvirt/images as well. > > This is a nice fit > /var/lib/rpm -> /usr/var/lib/rpm > > But it's an ask directed at those who have already implemented this > change, if it's compelling enough for them to change again. Sure, but my reasoning is that such an adaptation could be useful for multiple cases, not just the rpmdb case. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On 1/10/22 23:53, Chris Murphy wrote: On Mon, Jan 10, 2022 at 9:20 AM David Cantrell wrote: On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr == Summary == 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. [snip] Moving the RPM database to /usr feels incorrect to me, but we should move it to gain the improvements as noted in the feature proposal. Going back to the original discussions on moving rpmdb... Preferred is a new top-level location in /usr, .e.g /usr/sysimage/rpm. Next is "least worst" in /usr/lib/sysimage/rpm http://lists.rpm.org/pipermail/rpm-maint/2017-October/006764.html http://lists.rpm.org/pipermail/rpm-maint/2017-October/006722.html And the convergence was on /usr/lib/sysimage/rpm http://lists.rpm.org/pipermail/rpm-maint/2017-October/006785.html I don't see how /state solves the problem, rather than just rearranging the chairs. The problem with /usr/something is that the rpmdb is not specific to /usr contents at all, and unlike any other content in there, so putting it there just *feels so wrong*. That's what /state or /sysimage or, as we now have, /var supposedly solves. I thought I'd suggested something at / level back then (in https://lists.rpm.org/pipermail/rpm-maint/2017-October/006697.html and/or https://lists.rpm.org/pipermail/rpm-maint/2017-October/006699.html) but seems like memory is failing me :) Maybe I thought it would seem too outrageous to FHS believers to bother. The point was though, that the rpmdb is not at all the only data of this kind and so having a dedicated home makes sense. For many practical purposes it's probably just rearranging the chairs, but a separate top-level directory describing the *system* state seems instinctively *much* more correct solution to it than stuffing it somewhere deep inside a loosely related fs. Just FWIW, I would quit my whining about this right there if it went to a new toplevel directory instead because it just *feels* right unlike /usr. Numerous followups have noted the requirement that /usr contain read-only content, that it be shareable across hosts, and similar concepts. While this may or may not doable now like we could in the past, the bigger thing to me is around the understanding of what /usr contains. It is generally understood that /usr contains [most of] the installed system. What I think is a bigger requirement or expection now is that one can tar up /usr and transport it to another system or virtual machine or container and expect that it will _probably_ work maybe with a bit of tinkering. This is a really valuable thing to have for developers. Moving the RPM database to this tree adds a component that is unnecessary and sort of out of place. Should /usr be independently portable? And is that with a version matched /opt, or can there be mix and match revisions of /usr and /opt? If /usr is to be truly portable and have e.g. 'rpm query, verify, remove, reinstall' work as expected, you need the metadata (the database) representing its state to always come along for the ride. Either the database is already in /usr, or you have to make sure /usr and /state are inseparable. If /usr and /state are inseparable, and if rpm can also describe anything in /etc or /var or /opt, then all or part of those directories are also inseparable from /state. And thus /usr. So I think /state doesn't help. For one, /state (or whatever toplevel directory) allows for the fact that there are write-operations to rpmdb that do not touch any external files while maintaining read-only /usr. Such as rpmdb --rebuilddb, or rpm --import. And like mentioned in the original discussion and now here, although the discussion is on rpmdb, it's not the only data of this kind. To what degree do rpm and dnf intend to touch locations outside of /usr *and care* about tracking those changes? I don't understand the question. Rpm tracks and cares about all content it knows about equally, regardless of the path. /usr is NOT special in any way to rpm, it's just that most of *distro* content ends up in there but a huge number of packages have content spread across /etc too. I think rpm can't remain static for all time. It either needs to become aware of multiple root trees, and even mix and match top-level directories to create variable roots. And possibly even manage these things. Or it needs to constrain its reach to /usr and /opt. Whether /usr and /opt are tied together, or can be mix and match with their own rpmdb's, I have no strong opinion on. Oh, multiple rpmdbs. It's a while since that last turned up. It gets tossed around as a solution but to me it looks like it brings more problems than it solves. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org T
Re: New top-level dir: /state [
On Mon, Jan 10, 2022 at 10:55 AM Stephen Gallagher wrote: > A further quote from the same section of the FHS suggests the use of > /usr/var, which is a location we are not currently using in the Fedora > Project, but seems like it would fit the requirements for both CoreOS > and traditional RPM Fedora. This same hierarchy could be used for > /var/log and /var/lib/libvirt/images as well. This is a nice fit /var/lib/rpm -> /usr/var/lib/rpm But it's an ask directed at those who have already implemented this change, if it's compelling enough for them to change again. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Mon, Jan 10, 2022 at 9:20 AM David Cantrell wrote: > > On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote: > >https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr > > > >== Summary == > >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. > >[snip] > > Moving the RPM database to /usr feels incorrect to me, but we should move it > to gain the improvements as noted in the feature proposal. Going back to the original discussions on moving rpmdb... Preferred is a new top-level location in /usr, .e.g /usr/sysimage/rpm. Next is "least worst" in /usr/lib/sysimage/rpm http://lists.rpm.org/pipermail/rpm-maint/2017-October/006764.html http://lists.rpm.org/pipermail/rpm-maint/2017-October/006722.html And the convergence was on /usr/lib/sysimage/rpm http://lists.rpm.org/pipermail/rpm-maint/2017-October/006785.html I don't see how /state solves the problem, rather than just rearranging the chairs. > Numerous followups have noted the requirement that /usr contain read-only > content, that it be shareable across hosts, and similar concepts. While this > may or may not doable now like we could in the past, the bigger thing to me is > around the understanding of what /usr contains. It is generally understood > that /usr contains [most of] the installed system. What I think is a bigger > requirement or expection now is that one can tar up /usr and transport it to > another system or virtual machine or container and expect that it will > _probably_ work maybe with a bit of tinkering. This is a really valuable > thing to have for developers. Moving the RPM database to this tree adds a > component that is unnecessary and sort of out of place. Should /usr be independently portable? And is that with a version matched /opt, or can there be mix and match revisions of /usr and /opt? If /usr is to be truly portable and have e.g. 'rpm query, verify, remove, reinstall' work as expected, you need the metadata (the database) representing its state to always come along for the ride. Either the database is already in /usr, or you have to make sure /usr and /state are inseparable. If /usr and /state are inseparable, and if rpm can also describe anything in /etc or /var or /opt, then all or part of those directories are also inseparable from /state. And thus /usr. So I think /state doesn't help. To what degree do rpm and dnf intend to touch locations outside of /usr *and care* about tracking those changes? I think rpm can't remain static for all time. It either needs to become aware of multiple root trees, and even mix and match top-level directories to create variable roots. And possibly even manage these things. Or it needs to constrain its reach to /usr and /opt. Whether /usr and /opt are tied together, or can be mix and match with their own rpmdb's, I have no strong opinion on. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
> Am 10.01.2022 um 18:57 schrieb Alexander Sosedkin : > > On Mon, Jan 10, 2022 at 5:20 PM David Cantrell wrote: >> >> On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote: >>> https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr >>> >>> == Summary == >>> 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. >>> [snip] >> ... > > The whole proposal is kinda sad to read. > It's 2022 and we're catering to filesystem-level rollbacks. > Filesystem rollbacks *are* a gigantic unsubtle hammer > that should not be used in an automated manner, > or better yet, not used at all. > As much as you don't do filesystem rollbacks > to undo paragraph deletions in Libreoffice Writer, > you shouldn't do filesystem rollbacks to fix your system. > That's your package manager's / configuration manager's job. Well, os-tree is doing filesystem rollback / -rollforward by architecture. If you want to feed rpm into it, it may be tricky. But this argues for just moving rpmdb for rpm-oss-tree, since os-tree has its own logic anyway. No need and no advantage to do it for non-rpm-os-tree systems as well. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Mon, Jan 10, 2022, at 11:19 AM, David Cantrell wrote: > On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote: >>https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr >> >>== Summary == >>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. >>[snip] > > Moving the RPM database to /usr feels incorrect to me, but we should move it > to gain the improvements as noted in the feature proposal. > > Numerous followups have noted the requirement that /usr contain read-only > content, that it be shareable across hosts, and similar concepts. While this > may or may not doable now like we could in the past, the bigger thing to me is > around the understanding of what /usr contains. It is generally understood > that /usr contains [most of] the installed system. What I think is a bigger > requirement or expection now is that one can tar up /usr and transport it to > another system or virtual machine or container and expect that it will > _probably_ work maybe with a bit of tinkering. This is a really valuable > thing to have for developers. No, this is not about developers tar'ing up `/usr` by hand. It's about cleanly separating who owns what, and what its lifecycle is, which is critcially important for both "image based" updates as well as "local client side snapshots". Both these approaches end up creating more than one copy of certain files. See - https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/ - http://lists.rpm.org/pipermail/rpm-maint/2021-December/018770.html > Moving the RPM database to this tree adds a > component that is unnecessary and sort of out of place. I struggle to how to even respond to this. Multiple independent groups who *actually work* on image based updates and/or client side snapshots all generally agree that the rpmdb should be in /usr. That's where this Change came in. On what basis are you making this claim "unnecessary and sort of out of place"? > > "OK, but you can do tar -X" > > The tar example was simply that, an example. I feel the categorization of > system data is more important here. Panu brought this up on the referenced > RPM mailing list thread years ago. The original /var location for the RPM > database was fine, but we're at a point where we kind of have multiple > categories of things historically found in /var. > > Reading comments and talking to people, the long standing understanding of > /var is still "that's stuff you can rm -rf and the system will still work > fine". Yes, we call this "factory reset". https://github.com/coreos/fedora-coreos-tracker/issues/399 I am not sure where the terminology came from, but it is widely used when talking about e.g. mobile phones today. > Technically you could remove the RPM database and the system still > function, but arguably would still be broken since you really want the RPM > database. This use case of removing the RPM database and still having a > functioning system is really only useful for data recovery scenarios. You're > ultimately going to reinstall. Probably. At least from my PoV, the rpmdb is by default read-only (except to rpm-ostree) along with the rest of /usr, so you can't just rm -rf it alone. > So maybe the question is more "what is the correct location for data like the > RPM database?" First, how is that data different from the rest of /var? It > is host-specific, No. An image based updates model (both ostree and container images) ships a pristine copy that is bit-for-bit the same on every system. Container runtimes tend to make it mutable by default of course, but that doesn't change the fact that it's not by default host specific. > I would like to see Fedora introduce a new top-level directory called: > > /state We have years of investment in rpm-ostree in the current design. For example, the tooling supports `rpm-ostree db diff` which shows you the delta between the current and pending rpmdb. How would this new directory work? How would it better solve problems that are today solved with the location in /usr? And do you even have a sense of how much work would creating for the rpm-ostree stack at least with a new toplevel directory with new, as yet ill-defined semantics? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Mon, Jan 10, 2022 at 5:20 PM David Cantrell wrote: > > On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote: > >https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr > > > >== Summary == > >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. > >[snip] > > Moving the RPM database to /usr feels incorrect to me, but we should move it > to gain the improvements as noted in the feature proposal. > > Numerous followups have noted the requirement that /usr contain read-only > content, that it be shareable across hosts, and similar concepts. While this > may or may not doable now like we could in the past, the bigger thing to me is > around the understanding of what /usr contains. It is generally understood > that /usr contains [most of] the installed system. What I think is a bigger > requirement or expection now is that one can tar up /usr and transport it to > another system or virtual machine or container and expect that it will > _probably_ work maybe with a bit of tinkering. This is a really valuable > thing to have for developers. Moving the RPM database to this tree adds a > component that is unnecessary and sort of out of place. > > "OK, but you can do tar -X" > > The tar example was simply that, an example. I feel the categorization of > system data is more important here. Panu brought this up on the referenced > RPM mailing list thread years ago. The original /var location for the RPM > database was fine, but we're at a point where we kind of have multiple > categories of things historically found in /var. > > Reading comments and talking to people, the long standing understanding of > /var is still "that's stuff you can rm -rf and the system will still work > fine". That's one interesting definition of "fine" if it's OK with wiping the system's (arguably) *only* non-disposable directory. > Technically you could remove the RPM database and the system still > function, but arguably would still be broken since you really want the RPM > database. This use case of removing the RPM database and still having a > functioning system is really only useful for data recovery scenarios. You're > ultimately going to reinstall. Probably. > > So maybe the question is more "what is the correct location for data like the > RPM database?" First, how is that data different from the rest of /var? It > is host-specific, it's updated by tools we run all the time, and it's > stateful. Losing it would render the system not really useful, though the > system would still function. Am I missing anything here? > > As Lennart noted, we have lots of examples in /usr of changing data. But I'd > say the difference between those examples (library symlinks, cache files, etc) > and the RPM database is that the loss of something like a library symlink or > cache file can be repaired easily but if you lose the RPM database, the system > is in an unrepairable state. > > As another example... If you use Bitlbee, this would be like losing your > account XML file in /var/lib/bitlbee. Sure, bitlbee still works, but that > file is important for Bitlbee to work for you. You have to remember to hang > on to that if you wipe /var or reinstall or whatever. I'd say the Bitlbee > files in /var/lib/bitlbee also fit this slightly different /var data > definition, just as an example. > > "But what about the FHS?" > > Ah, yes, the FHS. So, I am a fan of the FHS. I actually don't care that it > doesn't change every week and is relatively stable. Nothing in the FHS > prevents the addition of new top level directories. > > I would prefer we steer this conversation in the direction of determining a > new top level location to store data that fits this category of "stateful but > variable". > > /srv was introduced to provide a consistent location for data in this category > for server daemons (except mail). > > /media was introduced to provide a consistent location for removable media > mount points since distributions all did things slightly differently. > > /run was introduced for what was traditionally in /var/run. > > "So what are you suggesting?" > > I would like to see Fedora introduce a new top-level directory called: > > /state > > That holds the RPM database and other variable and stateful data. This keeps > it out of the /usr tree and can serve as a location for future data in this > category. If I ever see a system with /state I'll automatically assume this is the only location that's not wiped on a reboot, invented because the admin gave up on denylisting useless stuff in /var. The whole proposal is kinda sad to read. It's 2022 and we're catering to filesystem-level rollbacks. Filesystem rollbacks *are* a gigantic unsubtle hammer that should not be used in an automated manner, or better yet, not used at all. As much as you don't do filesystem rollbacks to undo paragraph deletions in Libreoffic
Re: New top-level dir: /state [
On Mon, Jan 10, 2022 at 12:30 PM Frank Ch. Eigler wrote: > > David Cantrell writes: > > > Reading comments and talking to people, the long standing understanding of > > /var is still "that's stuff you can rm -rf and the system will still work > > fine". Technically you could remove the RPM database and the system still > > function [...] > > Considering that many other valuable mutable state are put under /var > are put there, databases, container images, etc. etc. etc, this > understanding cannot be correct. We could just leave /var alone. > > # sudo du -s /var/lib/* I *think* what David is suggesting here is that while databases and container images are indeed changeable data that lives in /var (and are likely VERY important to the user), they are not critical to the functioning of the operating system itself. The OS will still boot and you can still log in[1] if /var is wiped clean, though the system will probably not be doing anything useful at this point. Whereas if the RPM database is damaged or removed, a core function of the operating system (installation and updates) will no longer work. I think there is definite value in considering adding a new location (though it need not be at the top-level) for data like this. I'll note that the FHS states the following[2] in regards to /var: "Everything that once went into /usr that is written to during system operation (as opposed to installation and software maintenance) must be in /var." This exception seems to me to be clearly implying that "installation and software maintenance" do not need to be in /var (and as CoreOS has shown, there's value to keeping it somewhere else). A further quote from the same section of the FHS suggests the use of /usr/var, which is a location we are not currently using in the Fedora Project, but seems like it would fit the requirements for both CoreOS and traditional RPM Fedora. This same hierarchy could be used for /var/log and /var/lib/libvirt/images as well. [1] With the possible exception of enterprise logins, since SSSD stores its offline cache in /var/lib/sss/db [2] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05.html#purpose31 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Mon, Jan 10 2022 at 11:19:40 AM -0500, David Cantrell wrote: I would like to see Fedora introduce a new top-level directory called: /state Huh, a new top-level directory is a pretty big hammer. Seems like it would be a lot easier to just have two different locations for the rpmdb if non-ostree users really do not want it under /usr? Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [
David Cantrell writes: > Reading comments and talking to people, the long standing understanding of > /var is still "that's stuff you can rm -rf and the system will still work > fine". Technically you could remove the RPM database and the system still > function [...] Considering that many other valuable mutable state are put under /var are put there, databases, container images, etc. etc. etc, this understanding cannot be correct. We could just leave /var alone. # sudo du -s /var/lib/* - FChE ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
> Am 10.01.2022 um 17:19 schrieb David Cantrell : > > On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr >> >> == Summary == >> 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. >> [snip] > > Moving the RPM database to /usr feels incorrect to me, but we should move it > to gain the improvements as noted in the feature proposal. > > ... > "But what about the FHS?" > > Ah, yes, the FHS. So, I am a fan of the FHS. I actually don't care that it > doesn't change every week and is relatively stable. Nothing in the FHS > prevents the addition of new top level directories. > > I would prefer we steer this conversation in the direction of determining a > new top level location to store data that fits this category of "stateful but > variable". > > /srv was introduced to provide a consistent location for data in this category > for server daemons (except mail). > > /media was introduced to provide a consistent location for removable media > mount points since distributions all did things slightly differently. > > /run was introduced for what was traditionally in /var/run. > > "So what are you suggesting?" > > I would like to see Fedora introduce a new top-level directory called: > >/state > > That holds the RPM database and other variable and stateful data. This keeps > it out of the /usr tree and can serve as a location for future data in this > category. I would like to second David Cantrell's suggestion. For Fedora Server it seems to me essential to strictly follow FHS. And from an "enterprise" perspective, it is essential that FHS indeed does not change every week. A /state directory is not included in FHS, sure. But at least it does not blatantly violate existing and accepted regulations. And the fact that rpm-ostree based installations have already made this change is not a relevant argument for FHS based installations. Best Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
