DNFs log from the time period can be found here: http://www.leemhuis.info/files/misc/dnf-logs-hunspell-problem.tar.xz

Thanks a lot for reporting this.

Unfortunately (or not) it seems easy to reproduce.
I installed F35-WORK-x86_64-LIVE-20220301.iso in Danish for fun, and dnf updated.
Then with hunspell-da post-installed, I did a dnf system-upgrade to F36
and upon booting indeed all the hunspell-en* files had disappeared.

I take this if you want, Caolan.

(Actually in German, because my original Danish install hung at the end anaconda somehow.)

Here is some of the upgrade transaction output from journalctl:

Mär 15 20:13:53 fedora kernel: audit: type=1130 audit(1647346433.234:125): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=sy>
Mär 15 20:13:53 fedora dnf[630]:   Ausgeführtes Scriptlet: filesystem-3.16-2.fc36.x86_64                     1/1
Mär 15 20:13:53 fedora dnf[630]:   Ausgeführtes Scriptlet: selinux-policy-targeted-36.3-1.fc36.noarch        1/1
Mär 15 20:13:53 fedora dnf[630]:   Ausgeführtes Scriptlet: hunspell-filesystem-1.7.0-17.fc36.x86_64          1/1
Mär 15 20:13:53 fedora dnf[630]:   Ausgeführtes Scriptlet: firefox-96.0-1.fc36.x86_64                        1/1
Mär 15 20:13:55 fedora dnf[630]:   Ausgeführtes Scriptlet: alsa-sof-firmware-2.0-3.fc36.noarch               1/1
Mär 15 20:13:56 fedora dnf[630]:   Vorbereitung läuft    :                                                   1/1
:
:
Mär 15 20:16:51 fedora dnf[630]: /sbin/ldconfig: /lib64/liblber-2.4.so.2 ist kein symbolischer Link
Mär 15 20:16:51 fedora dnf[630]:   Aktualisieren         : libwinpr-2:2.5.0-1.fc36.x86_64               726/3195
Mär 15 20:16:51 fedora dnf[630]:   Aktualisieren         : xmlrpc-c-1.51.0-14.fc36.x86_64               727/3195
Mär 15 20:16:51 fedora dnf[630]:   Aktualisieren         : hunspell-filesystem-1.7.0-17.fc36.x86_64     728/3195
Mär 15 20:16:51 fedora dnf[630]:   Ausgeführtes Scriptlet: hunspell-filesystem-1.7.0-17.fc36.x86_64     728/3195
Mär 15 20:16:51 fedora dnf[630]:   Aktualisieren         : hunspell-en-GB-0.20140811.1-22.fc36.noarc    729/3195
Mär 15 20:16:51 fedora dnf[630]:   Aktualisieren         : hunspell-1.7.0-17.fc36.x86_64                730/3195
Mär 15 20:16:51 fedora dnf[630]:   Aktualisieren         : hunspell-en-US-0.20140811.1-22.fc36.noarc    731/3195
Mär 15 20:16:51 fedora dnf[630]:   Aktualisieren         : hunspell-en-0.20140811.1-22.fc36.noarch      732/3195
Mär 15 20:16:51 fedora dnf[630]:   Aktualisieren         : enchant2-2.3.2-3.fc36.x86_64                 733/3195
Mär 15 20:16:52 fedora dnf[630]:   Aktualisieren         : python3-libselinux-3.3-4.fc36.x86_64         734/3195
Mär 15 20:16:52 fedora dnf[630]:   Aktualisieren         : python3-systemd-234-20.fc36.x86_64           735/3195
:
Mär 15 20:17:23 fedora dnf[630]:   Aktualisieren         : python3-libsemanage-3.3-3.fc36.x86_64        948/3195
Mär 15 20:17:23 fedora dnf[630]:   Aktualisieren         : enchant-1:1.6.0-29.fc36.x86_64               949/3195
Mär 15 20:17:23 fedora dnf[630]:   Aktualisieren         : python3-enchant-3.2.2-2.fc36.noarch          950/3195
Mär 15 20:17:23 fedora dnf[630]:   Aktualisieren         : hunspell-de-20161207-2.fc36.noarch           951/3195
Mär 15 20:17:23 fedora dnf[630]:   Aktualisieren         : ndctl-libs-72.1-2.fc36.x86_64                952/3195
Mär 15 20:17:23 fedora dnf[630]:   Aktualisieren         : libpmem-1.11.1-4.fc36.x86_64                 953/3195
:
:
Mär 15 20:20:49 fedora dnf[630]:   Aufräumen             : gspell-1.9.1-3.fc35.x86_64                  2385/3195
Mär 15 20:20:49 fedora dnf[630]:   Aufräumen             : enchant2-2.3.2-1.fc35.x86_64                2386/3195
Mär 15 20:20:49 fedora dnf[630]:   Aufräumen             : hunspell-de-0.20161207-8.fc35.noarch        2387/3195
Mär 15 20:20:49 fedora dnf[630]:   Aufräumen             : hunspell-en-US-0.20140811.1-20.fc35.noarc   2388/3195
Mär 15 20:20:49 fedora dnf[630]:   Aufräumen             : hunspell-en-0.20140811.1-20.fc35.noarch     2389/3195
Mär 15 20:20:50 fedora dnf[630]:   Aufräumen             : hunspell-en-GB-0.20140811.1-20.fc35.noarc   2390/3195
Mär 15 20:20:50 fedora dnf[630]:   Aufräumen             : hunspell-1.7.0-11.fc35.x86_64               2391/3195
Mär 15 20:20:50 fedora dnf[630]:   Aufräumen             : texlive-lib-9:20210325-44.fc35.x86_64       2392/3195
:
Mär 15 20:21:28 fedora dnf[630]:   Aufräumen             : adobe-mappings-pdf-20180407-9.fc35.noarch   2998/3195
Mär 15 20:21:28 fedora dnf[630]:   Aufräumen             : hunspell-filesystem-1.7.0-11.fc35.x86_64    2999/3195
Mär 15 20:21:28 fedora dnf[630]:   Aufräumen             : kasumi-common-2.5-37.fc35.noarch            3000/3195
:
:
Mär 15 20:23:40 fedora dnf[630]:   Überprüfung läuft     : httpd-tools-2.4.52-1.fc35.x86_64            1123/3195
Mär 15 20:23:40 fedora dnf[630]:   Überprüfung läuft     : hunspell-1.7.0-17.fc36.x86_64               1124/3195
Mär 15 20:23:40 fedora dnf[630]:   Überprüfung läuft     : hunspell-1.7.0-11.fc35.x86_64               1125/3195
Mär 15 20:23:40 fedora dnf[630]:   Überprüfung läuft     : hunspell-de-20161207-2.fc36.noarch          1126/3195
Mär 15 20:23:40 fedora dnf[630]:   Überprüfung läuft     : hunspell-de-0.20161207-8.fc35.noarch        1127/3195
Mär 15 20:23:40 fedora dnf[630]:   Überprüfung läuft     : hunspell-en-0.20140811.1-22.fc36.noarch     1128/3195
Mär 15 20:23:40 fedora dnf[630]:   Überprüfung läuft     : hunspell-en-0.20140811.1-20.fc35.noarch     1129/3195
Mär 15 20:23:40 fedora dnf[630]:   Überprüfung läuft     : hunspell-en-GB-0.20140811.1-22.fc36.noarc   1130/3195
Mär 15 20:23:40 fedora dnf[630]:   Überprüfung läuft     : hunspell-en-GB-0.20140811.1-20.fc35.noarc   1131/3195
Mär 15 20:23:40 fedora dnf[630]:   Überprüfung läuft     : hunspell-en-US-0.20140811.1-22.fc36.noarc   1132/3195
Mär 15 20:23:41 fedora dnf[630]:   Überprüfung läuft     : hunspell-en-US-0.20140811.1-20.fc35.noarc   1133/3195
Mär 15 20:23:41 fedora dnf[630]:   Überprüfung läuft     : hunspell-filesystem-1.7.0-17.fc36.x86_64    1134/3195
Mär 15 20:23:41 fedora dnf[630]:   Überprüfung läuft     : hunspell-filesystem-1.7.0-11.fc35.x86_64    1135/3195
Mär 15 20:23:41 fedora dnf[630]:   Überprüfung läuft     : hyperv-daemons-0-0.36.20190303git.fc36.x8   1136/3195
:
:
Mär 15 20:24:50 fedora dnf[630]:   httpd-tools-2.4.52-5.fc36.x86_64
Mär 15 20:24:50 fedora dnf[630]:   hunspell-1.7.0-17.fc36.x86_64
Mär 15 20:24:50 fedora dnf[630]:   hunspell-de-20161207-2.fc36.noarch
Mär 15 20:24:50 fedora dnf[630]:   hunspell-en-0.20140811.1-22.fc36.noarch
Mär 15 20:24:50 fedora dnf[630]:   hunspell-en-GB-0.20140811.1-22.fc36.noarch
Mär 15 20:24:50 fedora dnf[630]:   hunspell-en-US-0.20140811.1-22.fc36.noarch
Mär 15 20:24:50 fedora dnf[630]:   hunspell-filesystem-1.7.0-17.fc36.x86_64
Mär 15 20:24:50 fedora dnf[630]:   hyperv-daemons-0-0.36.20190303git.fc36.x86_64

So my only current guess is that rpm is somehow removing the hunspell-en files as part of removing the f35 package.

Maybe someone has a better idea or explanation?

Proposing as F36 Blocker ^

If you could take it that would be great. Maybe it would be more straight forward to just update all the hunspell-foo in F36 to the hunspell dir and drop the backwards compat link.

So I tested my theory in F35 with:

sudo rpm -Uvh https://kojipkgs.fedoraproject.org//packages/hunspell/1.7.0/18.fc36/x86_64/hunspell-filesystem-1.7.0-18.fc36.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/hunspell-en/0.20140811.1/22.fc36/noarch/hunspell-en-US-0.20140811.1-22.fc36.noarch.rpm https://kojipkgs.fedoraproject.org//packages/hunspell-en/0.20140811.1/22.fc36/noarch/hunspell-en-0.20140811.1-22.fc36.noarch.rpm https://kojipkgs.fedoraproject.org//packages/hunspell-en/0.20140811.1/22.fc36/noarch/hunspell-en-GB-0.20140811.1-22.fc36.noarch.rpm

and indeed all the hunspell-en* files get removed by this update transaction.

Caolan might be right that dropping the compat symlink might be the way forward
if it is really not necessary,
unless rpm can detect that the files are still present through the symlink
and therefore should not be cleanup up?

Anyway I would like just to have the opinion on this from the RPM perspective.

(For more background context see the F36 Change:
https://fedoraproject.org/wiki/Changes/Hunspell_dictionary_dir_change)

TL;DR F35 /usr/share/myspell dir became a symlink to new /usr/share/hunspell/ in F36

See https://src.fedoraproject.org/rpms/hunspell/pull-request/5
which removes the symlink from hunspell-filesystem

Rawhide scratch https://koji.fedoraproject.org/koji/taskinfo?taskID=84256941

I will probably push this soon so that it may get into today's Rawhide compose.

Tested successfully in F35 Live with:

sudo rpm -Uvh https://kojipkgs.fedoraproject.org//work/tasks/6949/84256949/hunspell-filesystem-1.7.0-19.fc37.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/hunspell-en/0.20140811.1/22.fc36/noarch/hunspell-en-US-0.20140811.1-22.fc36.noarch.rpm https://kojipkgs.fedoraproject.org//packages/hunspell-en/0.20140811.1/22.fc36/noarch/hunspell-en-0.20140811.1-22.fc36.noarch.rpm https://kojipkgs.fedoraproject.org//packages/hunspell-en/0.20140811.1/22.fc36/noarch/hunspell-en-GB-0.20140811.1-22.fc36.noarch.rpm

Built as hunspell-1.7.0-19.fc37 first of all

So far LGTM: it is in today's rawhide compose (Fedora-Rawhide-20220316.n.0).

I don't know the details in this case but rpm does very much care about content reachable through symlinks, just that any filesystem rearrangements and symlinks to directories need to happen in %pretrans for rpm to know about them. It looks to me as if a compat symlink was added in %post here, which is far too late.

Oh and BTW, if you can get by without using %pretrans tricks, ALL THE BETTER. %pretrans is just plain evil.

+6 for Beta FE in https://pagure.io/fedora-qa/blocker-review/issue/672 , marking accepted.

(In reply to Panu Matilainen from comment #13)
> I don't know the details in this case but rpm does very much care about
> content reachable through symlinks, just that any filesystem rearrangements
> and symlinks to directories need to happen in %pretrans for rpm to know
> about them. It looks to me as if a compat symlink was added in %post here,
> which is far too late.

Oh I see, right, thank you.
Actually I forget why we had put the symlink creation in %post: now I don't see any particular reason for that.

With %pretrans symlink we might not need to %ghost it either?

Anyway for now it seems better to keep both directories, at least during the dictionary move transition period.

FEDORA-2022-e2ba2d3685 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-e2ba2d3685

Having been involved with some RPM symlink fun in the past myself, I've also looked into this, by running the upgrade transaction (mentioned in Comment 10) on a F35 system through gdb, and indeed - all the files are removed.

What happens here is the following:

1) %pretrans renames /usr/share/myspell to /usr/share/hunspell
2) the new version of hunspell-filesystem is installed into /usr/share/hunspell
3) %post installs the symlink /usr/share/myspell pointing to /usr/share/hunspell
4) the old version of hunspell-filesystem is removed, thus removing the contents of /usr/share/hunspell via the /usr/share/myspell symlink

This happens because the /usr/share/myspell path belongs to the old version of hunspell-filesystem and so RPM simply removes the files when removing that package, as it should, really.

Arguably, RPM should detect that /usr/share/myspell was recorded in the rpmdb as a directory (not a symlink) and thus not remove the contents of it in case it's not a directory at the time of removal, but regardless, changing the filesystem beneath RPM may, by design, result in undefined and/or undesired behavior, which is the case here.  Of course, the %pretrans workaround (also used in this package) is something that's officially[1] recommended in Fedora (until RPM can deal with this properly in the future), so that works.  It's the %post symlink creation that breaks it here.

Now, it does seem that simply moving the symlink creation to %posttrans instead of %post fixes the problem.  I tried rebuilding the package with that change and it worked (the files were preserved in /usr/share/hunspell and the symlink /usr/share/myspell was created), however there was a bunch of warnings:

  warning: file /usr/share/myspell/en_ZW.dic: remove failed: No such file or directory
  [...]

That's because the original directory in /usr/share/myspell isn't there, obviously, when RPM is removing the old package.  This still wouldn't be good UX...

Next thing I tried was to *copy* the files (instead of moving them) in %pretrans; that's a bit more expensive an operation, but it actually *worked*.  I just needed to adjust the %posttrans scriptlet to remove the (now empty) directory before creating the symlink, instead of checking for its presence (I used "rmdir" to ensure that it's not removed and the scriptlet fails in case it's non-empty for any reason).

That said, I know you've already decided to revert the dir move for now, and perhaps introducing a compat package would be a cleaner solution after all, so feel free to ignore the previous and/or reference it later :)

[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/#_scriptlet_to_replace_a_directory

FEDORA-2022-e2ba2d3685 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-e2ba2d3685`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e2ba2d3685

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Now that I've re-read my previous comment, I realize that maybe you might as well just not have the %pretrans there, let the new package install into /usr/share/hunspell and just create the symlink in %posttrans... but I'm not sure about all the implications off the top of my head, maybe there would be some?

Thanks Michal - right I think there are different possible solutions.
But at this point the development cycle I decided to err on the safe side.

Note the symlink was also breaking rpm-ostree upgrades/installs of dictionaries.
Also the updating of dictionary packages to the new location is still on-going.
After that we can revisit the symlink again, I suppose, if needed.

-3 in https://pagure.io/fedora-qa/blocker-review/issue/672 , marking rejected Final blocker (it's still accepted Beta FE).

FEDORA-2022-e2ba2d3685 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.