On Sat, Jun 14, 2025 at 04:42:06AM +0200, Neal Gompa wrote: > On Sat, Jun 14, 2025 at 1:21 AM Peter Hutterer <peter.hutte...@who-t.net> > wrote: > > > > On Fri, Jun 13, 2025 at 10:05:32AM +0200, Petr Pisar wrote: > > > V Fri, Jun 13, 2025 at 03:27:49PM +1000, Peter Hutterer napsal(a): > > > > Hi all, > > > > > > > > A tricky (for me) packaging question: > > > > xkeyboard-config 2.45 upstream changed the installation directory to > > > > make future multi-version installs possible. Traditionally files were > > > > installed in /usr/share/X11/xkb with an xkeyboard-config.pc pointing to > > > > those files (though that path is also frequently hardcoded). > > > > > > > > As of 2.45 XKB files are installed in /usr/share/xkeyboard-config-2/ > > > > with an xkeyboard-config-2.pc pointing to those files. > > > > > > > > xkeyboard-config.pc is provided for backwards compatibility and > > > > /usr/share/X11/xkb symlinks to the new install location. > > > > > > > > What I would like to do in Fedora: > > > > - new locations are packaged as xkeyboard-config and -devel > > > > - the /usr/share/X11/xkb symlink is packaged as xkeyboard-config-legacy > > > > - xkeyboard-config.pc is packaged as xkeyboard-config-legacy-devel > > > > > > > Why do you need to diverge the naming from upstream? > > > > > > I think a name of the pkgconfig file is an identifier referred from > > > other's > > > build script. Changing that name would break them. > > > > It's not diverging the name other than splitting the files from a single > > upstream into two packages. upstream installs both xkeyboard-config.pc > > and xkeyboard-config-2.pc. > > > > Long-term upstream expects the format to change but for backwards-compat > > reason we'll never be able to change the current version that's been in > > use for decades. So any current software will require > > xkeyboard-config.pc but can (at this point) be safely switched to > > xkeyboard-config-2.pc and get the same file (but in different paths). > > > > But at some point in the future xkeyboard-config.pc (and files) will be > > decoupled properly and frozen so it's standalone while the versioned > > approaches continue at their own pace. > > > > Anyway, that's the upstream plan, right now the TLDR is: > > xkeyboard-config upstream installs both .pc files so this is merely > > prep work so that in 10 years time we can install > > xkeyboard-config-legacy and xkeyboard-config-5, depending on which local > > applications we have that require XKB layouts. > > > > I think it probably makes sense to go ahead and just install the files > twice instead of using a symlink. If they are intended to change in > backward incompatible ways, then let's assume that they are for now.
Just to clarify here: xkeyboard-config-2 is identical and will stay identical to the old one (hence upstream with the symlink), so this is really a pure duplication. The backwards incompatible way will be in the next version (xkeyboard-config-3, whenever that one happens) so we'd then have 3 sets of XKB files (two exactly identical, 1 slightly different). > This obviates most of this discussion, because you'll just keep it a > directory and install the files there *and* the new location. It also > means that the legacy thing doesn't depend on the new thing and vice > versa. it'll also double the ~4MB of xkeyboard-config files for the 99.99% of users that don't have a custom keyboard layout in /usr/share. That's my main hesitation here. But I have yet to come up with a better option... Arguably in the time of rust, containers and flatpaks worrying about 4mb might be a bit out of date :) Cheers, Peter -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
