BUG: scrollkeeper support is fundamentally broken in darwinports

[rhwood@…]

Scrollkeeper is a system for maintaining documentation libraries so that documentation viewers can display help files that are scattered across a system. Scrollkeeper documentation collections are usually updated during "make install" which on dports is run during the destroot phase, resulting in multiple ports attempting to overwrite existing scrollkeeper files, and preventing the system from creating a caniconical set of scrollkeeper files that belong to no specific port.

This bug report is intended to be a placeholder against which specific scrollkeeper-related port specific bugs can be linked and is also a place for a generic solution to be posted, for implementation in specific portfiles.

[jmpp@…]

From your description of the problem, it seems to me like this should be considered as an infrastructure bug, what do you reckon? I'm not gonna change the component ( dports --> base) just yet because I would like to hear opinions.

-jmpp

[rhwood@…]

Clearly, we don't want any changes to the dp infrastructure to require that scrollkeeper be installed, although it would be nice if port maintainers did not have to concern themselves with how scrollkeeper works, but just make it a dependency and then have all things magically work. Perhaps we should revisit the question of if the fix should go in base once we figure out what the fix is.

[dmacks@…]

Two issues: 1. Prevent scrollkeeper docs from getting integrated into the system at build-time 2. Do integrate them eventually if scrollkeeper is available

Issue 1 is easy: pass --disable-scrollkeeper, if supported, or else patch out the scrollkeeper-update commands in the various Makefile.in

Issue 2 is easy in principle: run 'scrollkeeper-update' to resync the system with all scrollkeeper docs that are present. All you gotta do is figure out when/where/how to schedule that to occur.

[rhwood@…]

Unfortunately the flag --disable-scrollkeeper seems to also prevent the .omf file from being made when port whatever is built, meaning simply that there is nothing for scrollkeeper-update to update.

It seems that a better scheme of things would be to:

1) Let the port build with scrollkeeper

2) After the destroot phase (but before post-destroot commands are run), test for the existance of ${destroot}${prefix}/var/lib/scrollkeeper

3) Delete the above if it exists at detection time.

4) Run scrollkeeper-update at post-install with flags that are as of yet unknown

[rhwood@…]

Failed to mention:

The reason for testing for ${destroot}${prefix}/var/scrollkeeper between destroot and post-destroot phases was to try to either break ports that delete the above during post-destroot so that that code can be removed once port handles this situation correctly.

[dmacks@…]

comment #4 sounds like an upstream bug in the package. In the standard implementation of --disable-scrollkeeper (i.e., upstream uses gnome-doc-utils according to its docs), the *only* thing that the flag controls is whether scrollkeeper-update is run during 'make install' (and 'make uninstall'). I don't think scrollkeeper-update does anything other than "alter some /var/lib/scrollkeeper files", so simply deleting them sounds like a viable way to undo the effects of that command being run.

[rhwood@…]

Comparing the results of building eog with and without the --disable-scrollkeeper flag, I see absolutely no difference in the resulting build trees.

[dmacks@…]

The key phrase in comment #3 is "if supported". Which it ain't in eog. It's not listed in ./configure --help is it? This isn't some über-secret undocumented feature...it's a standard part of the new documentation toolchain to which gnome is gradually migrating. Try one of the packages listed on http://live.gnome.org/GnomeDocUtilsMigration

[rhwood@…]

I have been, as I note the need, fixing ports so that a configure.arg is --disable-scrollkeeper and adding a postinstall phase that includes system "scrollkeeper update"

This has been so far successful.

[rhwood@…]

Reassigning this bug to gnome-darwinports so I can mark it "Assigned" instead of "New"

[rhwood@…]

Marking this bug as assigned so that it does not show up in the list of new bugs.

This bug is now mostly informative. Do not know how to handle bugs of this type.

[rhwood@…]

This has been mostly fixed and individual tickets should be opened on individual ports as needed.