Menu
▾
▴
Re: [Scrollkeeper-devel] What about the distributions?
|
From: Eric B. <eb...@cy...> - 2000-10-19 10:33:31
|
Dan Mueth wrote:
>
> 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.
Forget about ">" and ">>". I used this notation without thinking. I just
wanted to state that the user's database had to be modified as a result.
Of course there should be more intelligence in that than shell
redirections.
> 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).
No, it's not either... either. We must make the system work with only
"./configure; make; make install" AND provide a solution for packagers:
In the "install:" section of the Makefile a full, working installation
must be performed.
AND
(We must provide a mechanism for merging the resulting database with a
bigger one
OR
We must ensure that each packaged database has a different name, and
that the help browsers can cope with many database files, namely one per
package)
> 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'.
No, this goes against RPM's principle of "pristine sources". A real
"make install" should be performed. The thing is we must think to the
life of the resulting data to transfer them between the build system and
the install system.
> 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.
Yes they will, just like Slackware's tgzs. The problem is not liked to
RPM technology, it's linked to the fact that the build system is not
necessarily the same as the install system.
I think you make too much confidence in debian's magic ;-).
> 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.
Well, I don't really see why the contents list should reside in a
different database. But this is another topic and maybe it's already
been discussed.
> 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?
The problem if you choose the solution of the different names is that
the help browser at some point has to know where the real docs and the
OMF information are. And storing this information somewhere at "make
install" time *IS NOT* enough.
--
Éric Bischoff - mailto:eb...@cy...
__________________________________________________
\^o~_.
.~. ______ /( __ )
/V\ Toys story \__ \/ ( V
// \\ \__| (__=v
/( )\ |\___/ )
^^-^^ \_____( )
Tux Konqui \__=v
__________________________________________________
|