As new models/features functionality are introduced they will only be
supported by the current version of ykman.

I've detailed solutions/workarounds in rhbz#2136583

The solutions/workarounds are not acceptable, hence opening this bug

Why aren't they acceptable?  It's extremely easy to install the new yubiauth-desktop app image if desired.  I put the instructions in the other bug ticket.  The new ykocli app also mimics the current functionality.  The new ykman is needed to stay current and provide support for new devices.  People need to move on.  Your solution is just perpetuates confusion and carries security risk since the old ykman will no longer be updated.  I don't agree with your approach.

Just to add on, I believe I understand the concern, but at the same time what about security and support issues going forward?  At what point do we move on?  I did investigate trying to package the flutter app, but as you know we don't have flutter in the repositories, so that would have to be packaged first.  Then, after looking at the new app, the dependencies were such that it didn't appear to lend itself to rpm packaging anyway.  What would be an ideal temporary solution would be to be able to package the old app solely for dependency purposes. I really don't believe depriving our users from a current, supported ykman is the way to go.  ykman is the provider of all the functionality, yubioath-desktop is just a gui frontend.

My desktop is aarch64 based, and all of the options are not available.
the linux download of the binaries are x86_64 only 
$ file Downloads/yubico-authenticator-6.0.2b-linux/authenticator 
Downloads/yubico-authenticator-6.0.2b-linux/authenticator: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not stripped
$ file Downloads/yubico-authenticator-6.0.2b-linux/lib/*
Downloads/yubico-authenticator-6.0.2b-linux/lib/libapp.so:                       ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[md5/uuid]=96e85afe3058bd68afad5dd1862b05e7, stripped
Downloads/yubico-authenticator-6.0.2b-linux/lib/libdesktop_drop_plugin.so:       ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
Downloads/yubico-authenticator-6.0.2b-linux/lib/libflutter_linux_gtk.so:         ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=cd6c7026702c6d0aad59bda8fdfb81e31e23db74, stripped
Downloads/yubico-authenticator-6.0.2b-linux/lib/libscreen_retriever_plugin.so:   ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
Downloads/yubico-authenticator-6.0.2b-linux/lib/liburl_launcher_linux_plugin.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
Downloads/yubico-authenticator-6.0.2b-linux/lib/libwindow_manager_plugin.so:     ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped

The snap version is 5.1 and also x86_64 only. Though I am not sure it is in the user's best interest to recommend using snap. While it seems it should work, it is not a good user experience. 

Outside of the technical issues, documenting what to do should not only be done in Bugzilla. This needs to be part of the Fedora 38 documentation and release notes. I only noticed it when upgrading to rawhide because I paid careful attention to the additions and removals. yubioath-desktop was removed as part of the transaction, sending me on a mission to figure out why and what was happening. I suspect that most users relying on yubioath-desktop will not pay as much attention and will then be left wondering what has happened.

I personally am using the app with a yubikey for ssh keys and 2fa authentications. I just installed and ykocli and it is not functional(I will file a separate bug):

$ ykocli 
Error: Multiple YubiKeys detected. Use --device SERIAL to specify which one to use.

       _          ____ _     ___ 
 _   _| | _____  / ___| |   |_ _|
| | | | |/ / _ \| |   | |    | | 
| |_| |   < (_) | |___| |___ | | 
 \__, |_|\_\___/ \____|_____|___|
 |___/                           
YubiKey 5C NFC (5.4.3) [OTP+FIDO+CCID] Serial: XXXXXX
YubiKey Standard (2.5.1) [OTP]
No matching entry found on YubiKey
You searched for ====> 
This script will now exit.

$ ykocli --device XXXXXX
Usage: ykman oath accounts code [OPTIONS] [QUERY]
Try 'ykman oath accounts code -h' for help.

Error: No such option: --device

       _          ____ _     ___ 
 _   _| | _____  / ___| |   |_ _|
| | | | |/ / _ \| |   | |    | | 
| |_| |   < (_) | |___| |___ | | 
 \__, |_|\_\___/ \____|_____|___|
 |___/                           
YubiKey 5C NFC (5.4.3) [OTP+FIDO+CCID] Serial: 19318408
YubiKey Standard (2.5.1) [OTP]
No matching entry found on YubiKey
You searched for ====> --device
This script will now exit.

I get that we need to continue to move forward, and I also get that my use case is not the most usual. If this is the path forward, it needs better documentation. and an acknowledgment that there are gaps. I will probably be limited to using my phone, it takes away the conveniences of the previous solution.

(In reply to Dennis Gilmore from comment #6)
> I get that we need to continue to move forward, and I also get that my use
> case is not the most usual. If this is the path forward, it needs better
> documentation. and an acknowledgment that there are gaps. I will probably be
> limited to using my phone, it takes away the conveniences of the previous
> solution.

Thanks for taking the time to test and give feedback.  Regarding the error, that is because ykocli is expecting you have a key inserted.  I will fix that.  If you can insert a key and then give it a test drive, I'd appreciate your comments if you have the time.  The code is modular so it's relatively easy to add more functions as they are needed.  Right now, it just does supports TOTP, ADD, DELETE and RENAME functions.  A background mode is also supported, but that is only available right now for KDE Plasma using Konsole.  
  
The whole thing is an unfortunate situation, and I'm trying my best to mitigate and providing some level of functionality.  I use 2FA all the time and know
that using ykman to obtain the codes isn't the most convenient experience.  That's why I worked on ykocli when it became obvious that the flutter app wasn't going to be able to be in the repositories anytime soon.

If I can't get things to what you would consider an acceptable state, you're probably correct and the path of least resistance will be to back out at least for F38.  I'm just concerned about support issues going forward.  Sorry for any grief I caused, and I'll also do the announcements, etc. if it looks like ykocli is a feasible workaround, since it will be needed for people who aren't using x86.

Sorry, you had multiple keys, I didn't plan for that, I will, but if you could test with just one key for the time being, I'd appreciate it.

Hi Dennis,
Thanks for the feedback on Bodhi.  I have now posted a discussion item here:
https://discussion.fedoraproject.org/t/f38-yubioath-desktop-yubikey-manager-qt-will-no-longer-be-available-in-fedora-repository/45921
Where I outline the mitigation options in greater detail.

I've also posted it on the devel and user mailing lists and, referenced it upstream here:
https://github.com/Yubico/yubioath-flutter/issues/926 (request for upstream ARM support)

and also created a ticket for inclusion in release notes.

I've recently made a few additions to ykocli in response to requests:
1.  Your issue regarding support for multiple inserted keys
2.  Addition of support for OATH accounts that have been configured to require a TOUCH
3.  Allowing users to modify colors through configuration options

I believe things should resolved now, so I'll close this.  If you don't agree, please
reopen.  Also, if you have any more suggestions for ykocli to improve it or fix an issue
please LMK.

Thanks for your help!  Much appreciated!