Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2127513 - Reconsider the -legacy subpackage split
Summary: Reconsider the -legacy subpackage split
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kbd
Version: 37
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Vitezslav Crhonek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-09-16 16:05 UTC by Adam Williamson
Modified: 2022-09-25 00:17 UTC (History)
2 users (show)

Fixed In Version: kbd-2.5.1-3.fc37
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-09-25 00:17:43 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Adam Williamson 2022-09-16 16:05:11 UTC 
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.
Comment 1 Zbigniew Jędrzejewski-Szmek 2022-09-17 09:20:16 UTC 
Yeah, sounds reasonable. Correct internationalized operations trumps saving 0.5 MB.
Comment 2 Vitezslav Crhonek 2022-09-19 09:07:54 UTC 
(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.
Comment 3 Vitezslav Crhonek 2022-09-20 07:19:08 UTC 
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.
Comment 4 Adam Williamson 2022-09-20 23:41:56 UTC 
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...
Comment 5 Fedora Update System 2022-09-21 09:34:33 UTC 
FEDORA-2022-ac8991ae06 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-ac8991ae06
Comment 6 Vitezslav Crhonek 2022-09-21 10:03:56 UTC 
I see, this is valid concern in my opinion and I made the package hard requirement.
Comment 7 Fedora Update System 2022-09-22 02:18:16 UTC 
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.
Comment 8 Fedora Update System 2022-09-25 00:17:43 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.