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.
Sure, I agree.
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.
...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.
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?
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...
(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?
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.