On Fri, Apr 3, 2020 at 10:41 AM Samuel Sieb <samuel@xxxxxxxx> wrote: > > On 4/3/20 6:09 AM, Richard Hughes wrote: > > On Fri, 3 Apr 2020 at 07:48, Samuel Sieb <samuel@xxxxxxxx> wrote: > >> The problem is that in the past there have been some packages that have > >> had to be updated first to successfully do the upgrade. > > > > So we list them with versions and do a deterministic check. Being told > > over and over and again "you need to make sure everything is up to > > date before upgrading" just isn't specific enough. e.g. > > [...snip...] > > > Asking the user to download 2Gb of updates so that they can download > > 2Gb of upgrades is just bad. If we need a "fixed" rpm of a specific > > version, we need to check for that version or newer. If we need to > > check that a specific package is not installed, then we check that > > package isn't installed. > > > > /me the gnome-software maintainer, that actually cares that a > > recommendation is actually possible to encode into code. > > I understand that, but it's a very difficult problem. QA can't test > every possible random combination of updates, so only a fully up-to-date > system is tested for upgrades. Personally, I make sure dnf, systemd, > repos, and release are updated before doing an upgrade. That's worked > for me so far, but I'm capable of fixing things if something goes wrong. > Although now that offline upgrades are the default, it's a lot safer. This is one of those cases where everyone is correct. Since offline update/upgrade mostly depends on the initramfs, I wonder if that could become exclusive so that upgrades entirely (and only) depend on the contents of the initramfs? a. Compose already creates a no-host-only initramfs, found on all install media. b. Clean installs create a no-host-only "rescue" initramfs, generated locally. This isn't the same as (a). e.g. Fedora 31 Workstation; ISO vs clean install, respectively -rw-r--r--. 2 root root 57536044 Oct 23 17:21 initrd.img -rw-------. 1 root root 83402982 Mar 17 22:31 initramfs-0-rescue-2d2b0efcba8442caaf742548b8b2e6ef.img c. The compose built initramfs happens many times per day, and openQA is testing all instances of it because that's the initramfs being used for booting the ISO. d. The locally generated rescue initramfs is not used or tested, except by manual intervention by the user. e. The locally generated rescue initramfs is not replaced on upgrades. It becomes stale. f. There's "Vague proposal: ship prebuilt initramfs images" time inspecific. But I wonder if we can fix all of these issues in one whack, and what we'd actually test and require as the prerequisite for upgrade is a particular kernel+initramfs combo. This would include dnf, PackageKit, rpm, systemd of the proper tested versions as a single testable "bundle". Gotcha is, the kernel+initramfs continues to get bumped on Fedora n-1 and n-2, for weeks after release and those aren't tested. But we already have that problem, and more, as those releases continue to drift from what was tested in the last weeks of the release process. So I still think a prebuilt initramfs would be a less fragile approach, that also doesn't require the obvious downloading waste. -- 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
