On Thu, Jan 13, 2022 at 8:34 AM David Cantrell <dcantrell@xxxxxxxxxx> 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 the > >rpm-ostree stack at least with a new toplevel directory with new, as yet > >ill-defined semantics? > > The proposal has asked to move the RPM database. I don't think /usr is the > correct location. I understand the words. I still don't follow the logic of why it's not correct, in particular if it is correct for rpm-ostree based systems but not correct for (traditional) RPM based systems. A sister distribution has made this decision already and not in a vacuum. All the same information available to us is available to them. Yet they are saying /usr/lib/sysimage is the correct location for rpmdb. It requires a stronger argument than provided so far to convince me they arrived at the wrong conclusion. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
