[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [installation-dev] Re: [dev] Re: Desktop integration for distributions [was debian-openoffice Announcing OpenOffice.org 1.0.1]

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

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?

[kbhend@localhost 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 :-).


To UNSUBSCRIBE, email to debian-openoffice-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: