Patches to automatically add/remove entries from info/dir

[fenner@…]

Here are some patches to base/src/port1.0 to automatically run install-info on installation, and install-info --delete on uninstall. They also delete a ${destroot}/${prefix}/info/dir file that the port may have installed (e.g. by running install-info on its own) so that it won't overwrite the one in the base system.

The two package methods were extended to perform this as well, except that .pkg doesn't seem to have an uninstall so the deletion won't happen.

[fenner@…]

Patch to add install-info handling to port1.0

[fkr@…]

Talked this over with landon, and he wants a more generic mechanism. I'll cc him in the bug, so he can comment on this too. -fkr

[fenner@…]

More generic in what way? An infrastructure of commands including

• "If a file matching this regexp gets installed in the install step, run this command" (with a parallel

for uninstall)

• "If a file matching this regexp gets installed in the destroot, delete it post-destroot"

and use them to implement the info infrastructure? I'd like the infrastructure to always do this for info files, since otherwise we would require the same N lines in each port that installs info files, which doesn't make much sense. Should the port be allowed to add to this list of meta- commands? Are there any other meta-commands you would like to see while I'm implementing?

[fenner@…]

Just to record some stuff from IRC.

Proposed primitives: on-install regexp command -- when "port install" comes across a file matching the regexp, it runs the command after copying the file. -- command is also put into the package on-deinstall regexp command -- when "port deinstall" comes across a file matching the regexp, it runs the command before deleting the file. -- command is also put into the package, if supported. on-finding-in-destroot regexp command -- post-destroot, checks for files matching regexp and runs command if found.

(note: glob would be better here, otherwise this requires a find since there isn't currently a

traversal.)

(note: there actually is a traversal to remove empty directories; if this functionality was

performed inside the port infrastructure it could

a) allow ports to supply a list of empty directories not to delete, obsoleting .turd files b) be combined with on-finding-in-destroot checks)

The infrastructure can have defaults, but the default regexps should be tight to prevent false positives, e.g. on-install (.*/info/)(.*.info) bad, on-install (${prefix}/info/([^{/]*\.info) better.}

I think perl could use this too for the autoload index.

[fenner@…]

Another thing that could use functionality like this is config files. If a port installs a foo.cf.sample it might want to copy foo.cf.sample to foo.cf iff foo.cf doesn't exist. This is probably common enough that the port author shouldn't be forced to write an on-install foo.cf.sample [ ! -f foo.cf ] && cp foo.cf.sample foo.cf (perhaps a macro that expands to the above? hmm...)

[jmpalacios (Juan Manuel Palacios)]

Milestone Needs developer review deleted

[raimue (Rainer Müller)]

I don't know much about GNU info. Is this 'install-info' still relevant? If so, we would have to run it after each activate/deactivate touching such a file (disregarding direct mode).

[cooljeanius (Eric Gallager)]

Cc Me!

[kannagi.cse@…]

Cc Me!

[com-macosforge@…]

This is apparently still not working? /opt/local/share/info/dir only has Aspell in it for me; the many other info files which are present in this directory aren't added to the index, which makes hard to browse these info files from either the standalone Info viewer or Emacs.

Perhaps the dir file could just be regenerated each time a package is installed/removed, if doing it incrementally is a problem?

[raimue (Rainer Müller)]

I don't think there is any problem. Just given the time this bug report is open, there seems to be little interest in this. We could regenerate the index every time a file in ${prefix}/share/info/ is changed by activate/deactivate.

For other such files, the index generation was implemented in the Portfiles and only later moved to a port group that the corresponding ports have to include. See the xmlcatalog port group​ and #41708. This could be implemented similarly for any ports installing info files.

The best solution would be to have generic triggers (as available in dpkg or rpm) that would be used to run such post-activate scripts without adding special support to Portfiles.