If you don’t have it already, please install the
asahi-platform-metapackage package. This package automatically pulls in platform dependencies, and will make sure you get any future packages needed for upcoming hardware/platform support, such as the upcoming audio-related packages.
Users who installed in the last couple of months should already have it. If you don’t, please install it now to make sure you don’t miss out on anything!
Is this coming the us poor Asahi Arch Linux ARM users, which don’t currently have time to switch to Fedora Asahi Remix, as well?
I get a conflict trying to install it
Last metadata expiration check: 1:16:07 ago on Tue 07 Nov 2023 07:56:53 AM MST.
allow_vendor_change is disabled. This option is currently not supported for downgrade and distro-sync commands
Problem: conflicting requests
- package asahi-platform-metapackage-0-3.fc38.noarch from copr:copr.fedorainfracloud.org:group_asahi:fedora-remix-scripts requires asahi-platform-metapackage-core = 0-3.fc38, but none of the providers can be installed
- package asahi-platform-metapackage-0-4.fc38.noarch from copr:copr.fedorainfracloud.org:group_asahi:fedora-remix-scripts requires asahi-platform-metapackage-core = 0-4.fc38, but none of the providers can be installed
- package asahi-platform-metapackage-core-0-3.fc38.noarch from copr:copr.fedorainfracloud.org:group_asahi:fedora-remix-scripts conflicts with kernel-devel provided by kernel-devel-6.4.11-401.asahi.fc38.aarch64 from @System
- package asahi-platform-metapackage-core-0-4.fc38.noarch from copr:copr.fedorainfracloud.org:group_asahi:fedora-remix-scripts conflicts with kernel-devel provided by kernel-devel-6.4.11-401.asahi.fc38.aarch64 from @System
- problem with installed package kernel-devel-6.4.11-401.asahi.fc38.aarch64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
I’ve been contemplating something similar for the x13s, but it would be nice if this were done automatically by initial-setup. A table of DMI->System/Board->Product Name to meta package table, which turns around and automatically installs the supporting userspace daemons/etc.
However, then I was thinking about how to do it automatically for specific bits of hardware, too. For example a USB-attached water-block, or UPS is detected, and then the liquidctl or apcupsd packages are automatically installed.
Our Arch spin always had similar metapackages since day 1, but the audio stuff will come to Fedora first (hint hint).
Some/many of the support packages here are hard requirements for the platform to function properly, e.g. the dracut stuff for firmware (needed for networking, USB, touchpad), the touch bar daemon (no touch bar = no F keys = no TTY switching). We’ll even need a subset of them for anaconda netinstall images, once we start supporting that flow. Since we have custom images anyway it doesn’t really matter for us, but it’s a bit different from platform support for other machines which tends to be more “add-on” ish and not so critical for basic functionality.
For external or add-on hardware though, certainly, some kind of mechanism to detect it and prompt to auto-install makes perfect sense.
kernel-devel. That is a 4K kernel package and useless here, we block those in the metapackage to avoid confusion. You want
kernel-16k-devel if you need the equivalent.
--allowerasing should do the right thing.