Fedora Account System
Red Hat Associate
Red Hat Customer
So I ran into yet another awful keyboard layout bug: https://bugzilla.redhat.com/show_bug.cgi?id=2121106 and in the course of thinking about that, I'm becoming increasingly convinced that splitting "legacy" layouts into a subpackage was a bad idea and we should revert it. The core problem is this: in several cases, we automatically configure a console layout that *only* exists in kbd-legacy. We do this at least for default installs in Russian - always the big case - and in several other cases, including at least any case where the xkb config is set to one of the "XX,us" pairs in https://github.com/systemd/systemd/blob/main/src/locale/kbd-model-map , which probably includes default installs in several other languages. Given this, I don't think it makes any sense for it to be a notionally-optional subpackage. As long as our layout config logic is expecting to be able to select "legacy" layouts, they are not really "legacy" at all, we need to expect that they will be there. One particular problem I noticed since switching to Silverblue is that Silverblue does not include kbd-legacy. I haven't tested yet, but I suspect when installing Silverblue in Russian or any affected language, you wind up with a US console keyboard layout, which obviously is not what we want. I can file an issue to put kbd-legacy in Silverblue, but this is just an illustration of why the split isn't a good idea and I think it should be reconsidered. We could potentially try to only include "important" legacy layouts in the main kbd-misc package, I guess, but that just seems like unnecessary work. I don't see a problem with just putting them all there. There aren't any conflicts, and IIRC we had loadkeys prefer the xkb-converted layouts where there's a name collision, so putting the legacy layouts into kbd-misc wouldn't suddenly cause people to start getting a legacy layout instead of an xkb-converted one where the same name exists in both directories.
Yeah, sounds reasonable. Correct internationalized operations trumps saving 0.5 MB.
(In reply to Adam Williamson from comment #0) > We could potentially try to only include "important" legacy layouts in the > main kbd-misc package, I guess, but that just seems like unnecessary work. I I agree. > don't see a problem with just putting them all there. There aren't any > conflicts, and IIRC we had loadkeys prefer the xkb-converted layouts where > there's a name collision, so putting the legacy layouts into kbd-misc > wouldn't suddenly cause people to start getting a legacy layout instead of > an xkb-converted one where the same name exists in both directories. Yes, that's true, xbk-converted layouts are searched first. I agree with you that it would be better to join -legacy with -misc. Or make -legacy again required by main kbd package as it was before.
What do you guys think about making it weak dependency? That would allow users who know what they are doing to exclude installing the -legacy package or remove it later.
My only concern about that is whether it'd be pulled in by all image compose tools and so on. I'm not entirely sure whether all of them pull in weak deps. And if anything it night give a message to spins that are concerned about space (like IoT) that this package can be left out, when it really shouldn't be...
FEDORA-2022-ac8991ae06 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-ac8991ae06
I see, this is valid concern in my opinion and I made the package hard requirement.
FEDORA-2022-ac8991ae06 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-ac8991ae06` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-ac8991ae06 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-ac8991ae06 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.