Workaround: { install-info /usr/share/info/diffutils* /usr/share/info/dir; }

(In reply to Christopher Yeleighton from comment #1)
> Workaround: { install-info /usr/share/info/diffutils* /usr/share/info/dir; }

1) what do we do if info package is not installed?

2) do we want a (rpmlint) check for all packages?

Individual packages are not meant to require "info", just like they don't require man when they ship man pages. If KDE has a component to render info pages by means of calling the external info command or relying on it's database, that KDE component needs to require the info package.

(In reply to Christopher Yeleighton from comment #0)
> { kioclient5 exec 'info:diffutils'; }
>  => handbook (OK but useless,
>  internal links do not work in Firefox — info: unknown protocol)

That's expected, the info: protocol is a KIO feature and Firefox does not use KIO.

> KDE Help directory
>  => no diffutils (bad!)

What do you mean by that? If I open KHelpCenter, I can navigate to the diffutils info page just fine.

(In reply to Jiri Slaby from comment #2)
> (In reply to Christopher Yeleighton from comment #1)
> > Workaround: { install-info /usr/share/info/diffutils* /usr/share/info/dir; }
> 
> 1) what do we do if info package is not installed?

If you had examined the build log, you would have realised that the trigger does not fire.  That is how triggers work.

(In reply to Ludwig Nussel from comment #3)
> Individual packages are not meant to require "info", just like they don't
> require man when they ship man pages. If KDE has a component to render info
> pages by means of calling the external info command or relying on it's
> database, that KDE component needs to require the info package.

KDE uses info2html which is not a part of info.

(In reply to Fabian Vogt from comment #4)
> What do you mean by that? If I open KHelpCenter, I can navigate to the
> diffutils info page just fine.

That probably means you have upgraded your system that had been installed at a time before %install_info was disabled.

(In reply to Jiri Slaby from comment #2)
> 2) do we want a (rpmlint) check for all packages?

First of all, we need a consistent way to handle the info registry that is not a parody of itself and that actually works.  Once we have that, we could add a warning similar to ldconfig.

I also see a problem with the test that verifies that the package can be installed and removed.  It does not verify triggers, as mentioned above.  I am not sure to have one that is feasible though.  It may be feasible wrt triggers but completely infeasible wrt file triggers.

(In reply to Christopher Yeleighton from comment #7)
> (In reply to Fabian Vogt from comment #4)
> > What do you mean by that? If I open KHelpCenter, I can navigate to the
> > diffutils info page just fine.
> 
> That probably means you have upgraded your system that had been installed at
> a time before %install_info was disabled.

Nope, I used the KDE live cd and reinstalled diffutils to work around excludedocs.

I see a different issue though, reinstallation/upgrades of the info package clear the info directory:

64f925a549c3:/ # rpm -U --replacepkgs /var/cache/zypp/packages/repo-oss/x86_64/diffutils-3.7-4.1.x86_64.rpm
64f925a549c3:/ # grep sdiff /usr/share/info/dir
* sdiff: (diffutils)Invoking sdiff.             Merge 2 files side-by-side.
64f925a549c3:/ # rpm -U --replacepkgs /var/cache/zypp/packages/repo-oss/x86_64/info-6.7-1.20.x86_64.rpm
64f925a549c3:/ # grep sdiff /usr/share/info/dir
64f925a549c3:/ # 

This is because first, the "new" info is installed and its %filetriggerin run, and after that the
%filetriggerun from the "old" info:

64f925a549c3:/ # strace -fetrace=execve rpm -U --replacepkgs /var/cache/zypp/packages/repo-oss/x86_64/info-6.7-1.20.x86_64.rpm
execve("/usr/bin/rpm", ["rpm", "-U", "--replacepkgs", "/var/cache/zypp/packages/repo-os"...], 0x7ffc4721a160 /* 9 vars */) = 0
strace: Process 483 attached
[pid   483] execve("/usr/bin/install-info", ["/usr/bin/install-info", "--info-dir=/usr/share/info", "/usr/share/info/diffutils.info.g"...], 0x7ffd501f7790 /* 9 vars */) = 0
[pid   483] +++ exited with 0 +++
strace: Process 484 attached
[pid   484] execve("/usr/bin/install-info", ["/usr/bin/install-info", "--quiet", "--delete", "--info-dir=/usr/share/info", "/usr/share/info/diffutils.info.g"...], 0x7ffd501f7790 /* 9 vars */) = 0
[pid   484] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=483, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
+++ exited with 0 +++

(In reply to Fabian Vogt from comment #10)
> This is because first, the "new" info is installed and its %filetriggerin
> run, and after that the
> %filetriggerun from the "old" info:

What if you use a package trigger instead?

I tried

%filetriggerun -n info -p <lua> -- %{_infodir}
io.write("arg[2]: ", tostring(arg[2]))
if arg[2] ~= 0 then
    -- Not an uninstallation
    return
end

However, it seems like arg[2] is always 0, not just on the final uninstallation. This seems to be hardcoded in rpm: https://github.com/rpm-software-management/rpm/blob/ef3ea9c69b7e5eddc9ad22c1832773e12bba1cb3/lib/rpmtriggers.c#L435

Apparently this was also reported for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1301677

Is there a way around this?

(In reply to Christopher Yeleighton from comment #11)
> (In reply to Fabian Vogt from comment #10)
> > This is because first, the "new" info is installed and its %filetriggerin
> > run, and after that the
> > %filetriggerun from the "old" info:
> 
> What if you use a package trigger instead?

It has to run on each (un)installation of a package containing info files, but there's nothing common to match there for a trigger.

The arg is zero because the trigger is called for a set of files, potentially belonging to multiple packages.

(In reply to Michael Schröder from comment #13)
> The arg is zero because the trigger is called for a set of files,
> potentially belonging to multiple packages.

Which would be just fine AFAICT. %trigger(in,un), are passed both the install count of "this" package and "the other" package after the script completed, which would be useful for %filetrigger as well. $1 would indicate whether the package containing the trigger is still installed after the script runs. $2 could indicate whether the file or triggering package still exists after the script runs.

In this particular case, it's that %triggerun is called for all installed files when info package is uninstalled/upgraded from. $1 would indicate whether it's an upgrade or an uninstallation.

See also https://github.com/rpm-software-management/rpm/issues/1370

There is no "the other" package, because a file trigger is triggered by a set of files.

(In reply to Michael Schröder from comment #16)
> There is no "the other" package, because a file trigger is triggered by a
> set of files.

Once per transaction? In that case, assigning a meaning to $2 is not easy. However, for this particular bug, only $1 is required.

No, not once per transaction (unless it's a "trans" file trigger).

The "filetriggerun" trigger is also run if the the package containing the trigger is deinstalled, in that case it will consume files from multiple packages.

(In reply to Fabian Vogt from comment #17)
> (In reply to Michael Schröder from comment #16)
> > There is no "the other" package, because a file trigger is triggered by a
> > set of files.
> 
> Once per transaction? In that case, assigning a meaning to $2 is not easy.

I checked the documentation again: "File triggers execute once for package". So %filetrigger(in,un) is called once for each triggering package (including itself), so there is a single triggering package for each call. Multiple packages owning a file would make that argument less useful, but that's also the case for %postun, isn't it?

> However, for this particular bug, only $1 is required.

On second thought I actually wonder why this only breaks on upgrade of the package containing the trigger (%filetriggerun is called), but not on upgrade of a triggering package (%filetriggerun is not called). As upgrades are basically installation of the new package followed by uninstallation of the old, that seems odd, but it might just not be (clearly) documented.

(In reply to Michael Schröder from comment #18)
> No, not once per transaction (unless it's a "trans" file trigger).
> 
> The "filetriggerun" trigger is also run if the the package containing the
> trigger is deinstalled, in that case it will consume files from multiple
> packages.

Yes, which is why $1 would be useful here. If $1 == 0, then it's not called as part of an upgrade.

> It has to run on each (un)installation of a package containing info files,
> but there's nothing common to match there for a trigger.

I have it the other way: %trigger -n diffutils -- info.

(In reply to Ludwig Nussel from comment #15)
> See also https://github.com/rpm-software-management/rpm/issues/1370

TL;DR: the uninstall trigger must run before the install trigger and no meta magic is going to fix that when a package update replaces one info file with another one.