[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 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?

[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 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 debian-openoffice-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: