Hi Kevin,
Kevin B. Hendricks wrote:
Hi Oliver,
these issues have been discussed over and over again, but everytime when
it comes to the work that has to be done to solve these issues, nothing
happened.
Unfortunately not many volunteers (including myself) understand the entire
instgall process well enought to understand what is doable and what isn't.
I do not understand the full installation process either, but most of it
(at least I hope so).
And I volunteeer to be the contact person for hamburg engineering if we
this project started.
I still don't understand the Basic pieces and I do not know how relocation
can and should be done. Doesn't setup2 do some string processing to
replace macros with actuals physical paths?
Yes, setup2 does macro replacements, but only for text files. There is a
special flag in the setup script that signals if a file contains such
macros, so they were easy to find. One way to do relocation would be to
identify and back-port all the code changes on 643 that eliminated
absolute paths statements in the configuration. Or we would have to
write a "relocation" tool, that changes the paths in the configuration
itself.
The basics scripts should not be that many. As soon as we exactly know
them, we can work on replacing their functionality. But I would like to
see the discussion of what is achievable already on the whiteboard
mailing list.
I propose to start a whiteboard project for a package based installation
process, where all the issues for a FHS/LSB conform issues can be
identified and discussed. Personnaly I think the best approach would be
to write tools that are able to read the setup installation scripts and
create package directly from solver.
Yes but would these be unix centric or completely cross-platform? The
reason I ask is how many other OOo specific libraries will these tools
really need (regcomp, basic, sal, ...)
I think regcomp e.g. should be installed with OOo and executed from a
rpm post-install script, so that the tools can be cross-platform as OOo
is. I thinks the steps we should take are:
1. Identify what setup2 does during a -net installation
2. Read and convert the setup.in[sf] script into something installer
specific - ignore everything that should be done different
3. Create packages with the chosen installer/package manager including
the information collected from step 2.
Therefor we would have to identify all setup basic scripts that run
during installation and recreate their functionality. Additionally we
may need a command line tool that is able to write to the OpenOffice.org
registry, but this shouldn't be too hard.
Yes, regcomp does exist but how many support libs does it need?
[EMAIL PROTECTED] bin]$ ldd regcomp
libsal.so.3 => ../lib/libsal.so.3 (0x0fe19000)
libcppu.so.3 => ../lib/libcppu.so.3 (0x0fdd1000)
libcppuhelper3gcc3.so => ../lib/libcppuhelper3gcc3.so (0x0fd5e000)
libdl.so.2 => /lib/libdl.so.2 (0x0fd3b000)
libpthread.so.0 => /lib/libpthread.so.0 (0x0fd05000)
libm.so.6 => /lib/libm.so.6 (0x0fc6e000)
libstlport_gcc.so => ../lib/libstlport_gcc.so (0x0fb7c000)
libstdc++.so.4 => /usr/lib/libstdc++.so.4 (0x0fa96000)
libc.so.6 => /lib/libc.so.6 (0x0f940000)
libgcc_s.so.1 => ../lib/libgcc_s.so.1 (0x0f913000)
/lib/ld.so.1 => /lib/ld.so.1 (0x30000000)
So whatever installation process we use is going to have to do things with
a bootstrap stage (that uses no special tools .. a shell script) to
unpack all of the special OOo specific libraries for all of these later
tools to work.
I would execute regomp from a post-install script as mentioned above.
I am particularly worried about how we create the XML files we need to
register things like spelling dictionaries, hyphtnation dictionaries, etc.
So we will need xml tools as well.
Agreed. Shouldn't be too hard.
Additional points I have in mind
- include the regcomp utility in the installation set to register
components - create a instdb.ins file if we keep the original setup for
the workstation install (and make it behave like a "first time wizard")
- change bootstrapping so that it no longer requires .sverionrc - ask
for inclusion of file typs into Gnome/KDE tree, so that we no longer
have to install these
But not everyone uses KDE and GNOME and setting file mime types is
important, isn't it?
I am all in favor of a whiteboard project to make a more unix-like
installer but we (the volunteers) are going to need some strong hints
about how to proceed to replace /use regcomp, xml-tools, and basic scripts
and more info on what is really going on during install so that we have
some idea of the best way to approach the problem.
I'll do my very best :-).
Oliver
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
