Opened 19 years ago

Last modified 13 months ago

#777 new enhancement

Patches to automatically add/remove entries from info/dir

Reported by: fenner@… Owned by: macports-tickets@…
Priority: Normal Milestone: MacPorts Future
Component: base Version:
Keywords: Cc: landonf (Landon Fuller), raimue (Rainer Müller), cooljeanius (Eric Gallager), kannagi.cse@…, mascguy (Christopher Nielsen)
Port:

Description (last modified by jmpp@…)

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.

Attachments (1)

info.diff (4.8 KB) - added by fenner@… 19 years ago.
Patch to add install-info handling to port1.0

Download all attachments as: .zip

Change History (16)

Changed 19 years ago by fenner@…

Attachment: info.diff added

Patch to add install-info handling to port1.0

comment:1 Changed 19 years ago by fkr@…

Cc: landonf@… added

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

comment:2 Changed 19 years ago by 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?

comment:3 Changed 19 years ago by 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.

comment:4 Changed 19 years ago by 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...)

comment:5 Changed 16 years ago by markd@…

Type: defectenhancement

comment:6 Changed 16 years ago by pipping@…

Milestone: MacPorts 1.4

comment:7 Changed 16 years ago by jmpp@…

Description: modified (diff)
Milestone: MacPorts 1.4Needs developer review
Owner: changed from macports-tickets@… to macports-dev@…
Priority: ExpectedNice to have

comment:8 Changed 15 years ago by jmpp@…

Milestone: Needs developer reviewMacPorts base bugs

Milestone Needs developer review deleted

comment:9 Changed 15 years ago by nox@…

Cc: landonf@… added; landonf@… removed
Milestone: MacPorts base bugsMacPorts base enhancements
Priority: Nice to haveNormal
Version: 1.0

comment:10 Changed 14 years ago by raimue (Rainer Müller)

Cc: raimue@… added

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).

comment:15 Changed 10 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:16 Changed 10 years ago by kannagi.cse@…

Cc: kannagi.cse@… added

Cc Me!

comment:17 Changed 8 years ago by 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?

comment:18 Changed 8 years ago by 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.

comment:19 Changed 13 months ago by mascguy (Christopher Nielsen)

Cc: mascguy added
Note: See TracTickets for help on using tickets.