Re: [Scrollkeeper-devel] Handling relocatable packages

[Laszlo K. <las...@su...>]

Dan Mueth wrote:
> 
> 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 :)
Yes, it sounds reasonable. (2) can be used if the docs go below the same
relative path. If they don't then (1) has to be used which is ok.

Besides I agree that there are loads of non-relocatable packages so the
option of not using the path updating script/binary should be kept. 

What about scrollkeeper-preinstall? How would it fit into this proposal?
It should be kept for non-relocatable packages probably.

Laszlo