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 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?
> 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, ...)
> 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 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.
> 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.
My 2 cents,
Kevin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
