Re: [Scrollkeeper-devel] What about the distributions?

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

On Wed, 18 Oct 2000, Eric Bischoff wrote:

> After:
> > --------------------------------
> > In the Makefile:
> > > install:
> > >         cp foo.sgml $(DOCDIR)
> > >         scrollkeeper-preinstall $(DOCDIR)/foo.sgml foo.omf > $(DOCDIR)/doc-contents.omf
> >
> > In the SPEC file:
> > > %Post
> > >         scrollkeeper-install $DOCDIR/doc-contents.omf
> > >
> > > %Postun
> > >         scrollkeeper-uninstall $DOCDIR/doc-contents.omf
> > >
> > > %Files
> > >	    $DOCDIR/doc-contents.omf
> > --------------------------------

Thanks Eric.  It is very nice to get input from somebody who knows a lot
about packaging.

I generally like this approach.  I have a few concerns:

1) Say we have foo/app1/docs/app1_doc1 and foo/app2/docs/app2_doc1.  Then
scrollkeeper-preinstall will overwrite $(DOCDIR)/doc-contents.omf twice
and the final would only have the last doc listed. We could use ">>", but
if $(DOCDIR)/doc-contents.omf happens to pre-exist, then we keep whatever
crud was in it from before.

2) As Ali pointed out, it seems to be hard to "have our cake and eat it
too". Either 'make install' actually calls scrollkeeper-install on the
local machine (as needed by tarball installs), or else it doesn't (as
people who want to merely create an RPM but not install it would prefer).  
The solution eludes me, although I'm sure this has been encountered many
times in the past and there must be some nice solution.  A not too nice
solution would be to have a separate target that the spec file calls
instead of 'install'.  So we'd have 'make install' and 'make
installforrpm'.  This seems inelegant though.  Any RPM experts out there
who would like to point out the solution?  Eric?  Also, I am trusting that
deb's will not pose any new problems here.

3) Do deb's let you control where the deb installs?  The way we are doing
things now, we are writing the path of the SGML file into the OMF metadata
in the pre-install script. So if the installer has any power to change
where things get installed (say under /share instead of
/usr/local/share) then everything breaks.

4) Did you literally mean to use the name "doc-contents.omf"?  This makes
me think of the contents list which isn't really what this file is.  If I
understand you (Eric), this is basically just a file with all the OMF
files concatenated and possibly a bit more info if necessary.  Also, since
there is a possibility of multiple packages installing docs into the same
directory, we probably want to give them unique names. Perhaps
$(DOCDIR)/<packagename>-docs.omf?

Dan