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

[Ali A. <ALI...@au...>]

On Wed, 18 Oct 2000, Dan Mueth wrote:

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

There is a solution to this. Include a patch to the RPM that will 
"modify" the tarball to NOT run scrollkeeper-install (patches can be 
"attached" to RPMS (RedHat does it, but I do not know the technical side 
of how it is done)). This is the only "sound" solution I can think of. 
Debian dudes have their own patches to handle stuff :) 

Unfortunately, you have to ask yourself - Will application writers want 
to do this for their packages?
 
> 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
> 
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> http://lists.sourceforge.net/mailman/listinfo/scrollkeeper-devel
>