[lsb-discuss] A day's adventure with a brandnew klik bundle of OpenOffice.org 2.1

[Kurt Pfeifle]

On Saturday 16 December 2006 07:09, Thorsten Kukuk wrote:
> On Sat, Dec 16, Kurt Pfeifle wrote:
> 
> > On Wednesday 13 December 2006 08:06, Thorsten Kukuk wrote:
> > > On Wed, Dec 13, Kurt Pfeifle wrote:
> > > 
> > > > 
> > > > ---------------------------------------------------------------------
> > > > OpenOffice.org 2.1 released... But where can I get packages for my  
> > > > SuSE 9.1 box? Or even for a more recent SUSE 10.0? *NOW*, I mean !!
> > > > ---------------------------------------------------------------------
> > > > 
> > > > Diary of Dec 12, 2006. 
> > > > 
> > > > OpenOffice.org version 2.1 has been released.
> > > > 
> > > > 1st Question: 
> > > >    Is there available, or will there be a suitable OOo 2.1 RPM 
> > > >    package for my good ol' SuSE 9.1 box?
> > > > 1st Answer: 
> > > >    No, there is none, and most likely there will never be one. 
> > > >    SuSE/Novell don't support that "old" system any longer.
> > > > 1st Solution: 
> > > >    Download probono's ready-made klik package [p] from the klik 
> > > >    website [w] and use this. Works like a charm for me, on SuSE 9.1.
> > > 
> > > which raises one question to me: Which glibc will be used?
> > > (same is true for other depending packages)
> > > 
> > > - The one from the system?
> > 
> > Yes.
> > 
> > >   -> You need to compile the application on the oldest
> > >   availabe system, 
> > 
> > You seem to not yet be aware of some "inner mechanics" of klik:
> > 
> > klik does not (as a rule; there are exceptions) compile applications 
> > from sources. klik re-packages one (or more, if direct dependencies 
> > require this) .rpm, .deb, .tgz or (auto-).package packages into one
> > (1) .cmg file (a "Compressed iMaGe" archive file system; with cramfs)
> > and provides a helper script that is able to loopmount and start up
> > that .cmg from whereever it is stored.
> > 
> > So klik does not deal with building/compiling from sources and does
> > not want to compete with traditional systems on this field. 
> 
> It does not matter if klik care about building/compiling from
> sources or not, somebody has to do.

Of course  :-)

And we never were in denial of this.  :-)

I just wanted to express this: 

 * we don't have any strong stakes in either RPM or .deb package
   formats for the base system, 
 * and we don't make redundant the work of all these thousands of 
   packagers who serve the community (and the Linux companies).

> > Think of klik as a "web service" if it helps; a web service that
> > provides all the convenient functions to a user who just needs
> > to type in "klik://openoffice" into his browser (Firefox, elinks
> > or Konqueror) or click on such a link, to get and run the latest 
> > OOo version on whichever Linux system he currently uses.
> 
> So klik would need a dependency solver which checks, if the
> application can run on that system or not.

Yes. 

Or: klik will just run on any LSB 3.x/4.x based system (whatever that
    does mean in the end), because we'll then have a well defined set
    of base libraries and their respective versions.

Of course, there are a lot of extensions to the current klik design
conceivable: a complete infrastructure and environment of klik helper
tools for the klik client: these could do a lot checking and background
work, or automatic updating of program start menus, or automatically
re-assign mime types to applications. 

Currently, klik works in a very basic way without any pre-installed 
infrastructure (and also fails on certain occasions), because it is 
designed to provide that basic functionality "standalone". (Here 
standalone of course also requires a *minimal* infrastructure: the 2 
shell scripts .klik and .zAppRun, the loopmount entries in fstab and 
an assortment of *.desktop, *.protocol and .directory files).

We are open to any such extension and the creation for a klik client 
infrastructure -- provided one condition is met: it must not be a
requirement for klik bundles to work. klik needs to give the same
basic functionality as today to every Linux user even if she/he 
*doesn't* have a fully-fledged klik client environment installed. 

Thanks Tux, such a future klik client infrastructure can easily be 
designed to meet this condition, and just add more functions and more 
convenience to the Linux desktop user.

>    Thorsten

Cheers,
Kurt