Bug 1891811

Summary: Stop kbd base package depending on kbd-legacy
Product: [Fedora] Fedora Reporter: Peter Robinson <pbrobinson>
Component: kbdAssignee: Vitezslav Crhonek <vcrhonek>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: awilliam, fedoraproject, redhat-bugzilla, vcrhonek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: kbd-2.3.0-4.fc34 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-29 10:55:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1269538, 1734342    

Description Peter Robinson 2020-10-27 12:31:11 UTC
The legacy subpackage was created in May 2013 with the comment "Temporarily require -legacy". I think 7+ years later we should drop the requires on legacy. It uses up about 1.2Mb as it gets pulled into the initrd and is unlikely to be useful for most Fedora users.

Comment 1 Vitezslav Crhonek 2020-10-29 08:26:59 UTC
Sure, I agree.

Comment 2 Adam Williamson 2021-01-23 00:32:03 UTC
Well. It's actually useful / required for anyone who uses a language that requires a switched console layout. Including Russian. Which is quite a lot of people. The xkb-converted layouts for switched languages are useless.

Try it yourself - in current Rawhide, without kbd-legacy installed, do "loadkeys ru" and try to figure out how to type any Russian characters.

We either need this dependency back, or we need something somewhere to ensure kbd-legacy gets installed when we actually need one of the layouts from it. We could I guess try and do a reduced subpackage of just the "useful" legacy layouts, but that might be a source of potential future problems somehow...

I'll file a new bug for the problem this has caused, for clarity.

Comment 3 Adam Williamson 2021-05-04 06:37:13 UTC
...and as it turns out, we messed up F34 for Russian (and other switched layout language) users :(
https://bugzilla.redhat.com/show_bug.cgi?id=1955162
no-one thought to add kbd-legacy to the correct comps group to make sure it's actually on the install and live media. Unfortunately the openQA Russian install test uses the Everything repo (I'm not sure why we set it up that way, I'll have to check) so it did not catch this.

Comment 4 Adam Williamson 2021-05-04 16:25:30 UTC
So, hum, WDYT of this as an alternative idea? We tweak the magic in kbd.spec so that, after all the converting and wiping non-usable converted maps is done, we generate a list of maps that exist in legacy but not xkb, and include those in the main 'kbd' package? But where a map exists both in xkb and legacy, we leave the 'legacy' version of it in the kbd-legacy package?

Comment 5 Adam Williamson 2021-05-04 16:26:53 UTC
or, hmm, it might need to be even cleverer; we might need to include only maps that exist in legacy and xkb, but whose converted version was deleted by the 'can't input ASCII' check...to avoid including random legacy maps we don't really care about that just don't have xkb equivalents...

Comment 6 Vitezslav Crhonek 2021-05-05 08:03:35 UTC
(In reply to Adam Williamson from comment #5)
> or, hmm, it might need to be even cleverer; we might need to include only
> maps that exist in legacy and xkb, but whose converted version was deleted
> by the 'can't input ASCII' check...to avoid including random legacy maps we
> don't really care about that just don't have xkb equivalents...

This sounds good. But is it needed after adding kbd-legacy to the anaconda-tools group in comps?

Comment 7 Adam Williamson 2021-05-05 15:53:52 UTC
It's not strictly needed, but it feels like a 'better' approach to me. And it would mean we wouldn't need to include the truly "legacy" layouts in live images, I guess. I did stare at the spec for a bit yesterday but my bash-fu wasn't feeling up to a neat solution, though.