[Scrollkeeper-devel] Handling relocatable packages

[Dan M. <d-...@uc...>]

Hi everybody,

I've been trying to think of a solution to the problem of our current
ScrollKeeper design not handling relocatable packages properly. (ie.
packages where the installation location can be determined at install
time, after the package was built).  I think I have a solution.

Before I get into my idea, I wanted to ask people who actually supports
and uses relocatable packages?  Apparently all of Red Hat Linux and GNOME
are non-relocatable.  Nick has indicated that *BSD at least sometimes uses
relocatable packages.  I'm curious which operating system / packaging
system / distributions actually support and use relocatable packages.

My suggestion:

For non-relocatable packages, everything stays exactly as it is now and
was described in proposal #3.

For relocatable packages, we provide an extra script
('scrollkeeper-update-identifier') which can be called as a post-install
script before 'scrollkeeper-update' to "fix" the doc path in the
IDENTIFIER field of the OMF file.  This makes a little bit more work to
make your package relocatable, but I don't think that should surprise
anybody.

To make things as convenient as possible, we probably want to make
scrollkeeper-update-identifier flexible to handle a few different common
ways a person would want to use it:

1) scrollkeeper-update-identifier <omffile> <doc>
eg: scrollkeeper-update-identifier /usr/share/omf/foo.omf
/use/local/doc/foo/foo.sgml

It simply verifies that <doc> exists and then sticks <doc> into <omffile>
as the IDENTIFIER.

2) scrollkeeper-update-identifier <omffile> <path>
eg: scrollkeeper-update-identifier /usr/share/omf/foo.omf
/use/local/doc/foo/

It first reads the IDENTIFIER in <omffile>.

A) If the IDENTIFIER is just a file name it looks in <path> for the file.
If it does not find it there, it descends any subdirectories, searching
for the doc.

B) If the IDENTIFIER is a path with a file name, it tacks that onto <path>
and then looks for that file.  This way a person could set up all their
OMF files initially to hold relative paths to the doc from the main
director(ies) they are installed in.  So the relative paths are specified
at build time, and the toplevel directory for the doc is specified at
install time.

I think this should make it fairly easy for people to use.  If you have
many docs, you would probably want to place relative paths in the original
OMF files. Then in the post-install part of the package, loop over all
these OMF files passing the <path> under which all of the docs are
installed. (Similar to what was done in the 'info' installation example
Nick pointed out.)

After all the OMF files have their IDENTIFIERs updated, one runs
'scrollkeeper-update' as usual.

Does this sound reasonable to everybody?  Feedback is welcome :)

Dan