Re: [Rpm-ecosystem] [Rpm-maint] RFC: Relocate RPM and DNF databases to /usr
* Colin Walters: > On Wed, Dec 15, 2021, at 5:34 PM, Florian Weimer wrote: >> * Chris Murphy: >> >>> Fedora 36 seems like a good time to do this. What do you think? >> >> It's a bit odd to locate a database under /usr that isn't pre-built and >> installed. > > Why is that odd? Mentally, I still associate /usr with something that can be mounted read-only from shared storage. >> I guess in theory there could be systems with a read-only >> /usr out there that still allow installation of packages into /opt. >> >> Does it really help to improve the snapshot situation? > > Yes. > > I didn't wake up one day and say "hey you know what, today I'm going > to move the rpm database just for fun". Neither, for that matter did > the OpenSUSE folks. We haven't had this conversation over and over > throughout the years just because it was some minor thing. > > What I *did* wake up one day and say I'm going to do is make upgrades > transactional and offline by default and hence safe. No one should > ever fear starting an operating system upgrade while their laptop is > at 30% battery. Administrators running important servers must be able > to easily roll back when the kernel *or* systemd (or something) else > regresses, because it's software, it regresses all the time despite > our best efforts. I appreciate these efforts. Although transactional-update (as documented below) seems have one major regression: transactional RPM updates now require reboots. 8-( > So yes again, this does matter. And it matters because whether you're > doing "image based upgrades" like ostree or just "client side offline > updates" like the > https://kubic.opensuse.org/documentation/man-pages/transactional-update.8.html > thing - it's very important *what data specifically* is > versioned/snapshotted and what isn't. On an ostree system for > example, it's completely normal that there are *two* rpm databases > (one you're running, one that's pending in the new root). > > All the data in the rpmdb is about content that's in `/usr`. That totally ignores Software Collections and packages from ISVs. If the expected future that RPM is going to be an OS-internal software deployment mechanism (and not be used for third-party software), it should not be a side effect of this change, but an explicit decision. Thanks, Florian ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] rpm debugedit as a separate project?
* Neal Gompa: > On Sun, Feb 21, 2021 at 10:19 PM Mark Wielaard wrote: >> The code in rpm debugedit only deals with 128, 160, 256, 384 or 512 >> bit build-id lengths. See the hashing algorithms it tries. So making >> sure we support at least those lengths will make sure we don't regress >> in support. If you find other lengths in use then I am sure we can >> make the code deal with that. > > I'm pretty sure I recently saw something that wasn't in those sizes > for Go, but I'll have to look again. The build-id support for these > languages is kind of inconsistent. :( I think those aren't GNU build-ids: $ readelf -nW /usr/bin/go Displaying notes found in: .note.go.buildid OwnerData sizeDescription Go 0x0053 Unknown note type: (0x0004) description data: 69 69 77 57 6b 48 31 75 62 37 35 7a 42 71 73 33 45 52 74 2d 2f 52 33 4b 31 72 43 56 38 6c 4b 65 67 55 2d 56 79 67 7a 55 74 2f 39 5f 50 61 51 5f 4e 59 6e 53 46 7a 77 51 53 4a 4c 6c 68 74 2f 76 63 63 57 78 4f 37 6f 78 6e 32 52 56 33 46 38 6d 54 46 49 So the tools should be fine with that. Thanks, Florian ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Announcing DNF 3 development
On 03/22/2018 01:40 PM, Daniel Mach wrote: We are pleased to announce that development of DNF 3 has started. This version is focused on performance improvements, new API and consolidating the whole software management stack. Please read more details on our blog: https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/ “C++ 11 is supported by GCC in RHEL 7 / CentOS 7” — You should use Developer Toolset to compile on Red Hat Enterprise Linux 7 if you need C++11 support. The system compiler, GCC 4.8, has limited support only. Thanks, Florian ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] [RFC] Standardizing RPM macro for out-of-tree builds
On 10/17/2016 04:37 PM, Igor Gnatenko wrote: Hi, during last FPC meeting we agreed[0] that we need some standardization of macro related to builds where builddir != srcdir (and with possibility to make it builddir = srcdir). I was working to make guidelines for ninja and meson. For ninja it doesn't matter from where you build (it's like make), For make and ninja-build, what works depends on the recipes. I don't think there are ways to tell in an automated way if out-of-tree builds are supported or not. (There are also out-of-tree builds which still write to the source tree.) Florian ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
