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

[Kurt Pfeifle]

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. 

  (We are very much friends of the various tools the autopackage 
  maintainers have developed to gain "cleaner compiles"; we are 
  very much friends with the apt system developed by Debian; we 
  are also hoping very much for LSB 3.x or 4.x to succeeed in 
  defining a "base system" that will reliably be "the same" for 
  all certified distributions to keep the builtin [direct] cmg
  dependencies of each klik cmg-bundle at a minimum and make it 
  truly re-locateable across distributions; but we are basically
  "agnostic" of the input package format: klik can process .rpm
  as well as .deb, .tgz, .tar.gz, .tar.bz .tbz, .tar.bz, tbz2,
  tar.bz2 and .package "ingredients" into portable .cmgs -- we
  don't care. However, due to superior apt dependency resolution
  done automatically by our "server side apt", currently klik 
  uses more .debs [and Debian mirrors to fetch the ingredients
  from] than anything else...)

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.

BTW, the OOo 2.1 .cmg discussed here was made from the pre-compiled
Oo_2.1.0_LinuxIntel_install_en-US.tar.gz binary tarball (and no
additional "dependency" at all) that is offered by the OOo-owned
downloads.openoffice.org itself.

>   but very often you cannot compile new packages on 
>   such old systems (for example because of missing C++ support).

We know klik is not perfect (yet); it is more an alpha proof of 
concept (albeit one which works very well for QA-d packages) than
a very polished final version. But even this alpha version already
does a better job for quite a few use cases than the legacy Linux 
software installation methods do...

A lot of features can still be added. What I wanted to achieve with
describing how the new OOo 2.1 klik bundle worked out in my office 
neighbourhood is to make people on this list aware of some such use 
cases and how they are solved by klik.

But since I do not know exactly what configure options the upstream
OOo "packagers" of the Oo_2.1.0_LinuxIntel_install_en-US.tar.gz 
tarball used (I didn't closely look into the archive), I can not 
tell exactly *how* old the build system host was.

In any case, here it is obvious that the brandnew OOo 2.1 release
was built in a way that enables the klik conversion into .cmg to
make it run on SUSE 9.1-10.2, as well as on various other (probably
on 99% of all "Linux systems with a GUI") with minimal effort by
the user.

> - klik includes an own glibc
>   -> this limitates the allowed used functions to such ones which are
>   allowed for static linking. 

No klik bundle ever included its own glibc. (Probably some ISV 
software we made klik-able -- like skype, acroread, opera, xara,
realplayer and more -- did do this for their static linking; but in 
most of these cases that's what you would get by installing the 
same vendors' RPMs or .debs as well....)

klik does not need to use static linking. And if it needs to include
a certain direct dependency (because it may be uncommon as a system-
installed package on most users' systems, or because its exact 
version may be critical to the functioning of the software itself) 
it can be packed into the .cmg as a dynamically linked lib. However, 
if statically linked "ingredients" is all that's on offer in certain 
cases, klik is also able to use these.

>   No NSS functionality will work reliable. 
>   But now the user informations are stored in LDAP, so user has lost?

Specifically, I do not know if LDAP-stored user info will work for
the current OOo 2.1 bundle (I have no test environment here for 
checking this); we'd be happy to hear reports and feedback from
you.

Even *if* features are missing, users have not "lost" permanently 
either: it's dead-easy to build another edition of an ooo-2.1.cmg
once superior Novell RPMs are available (ones that support NSS/LDAP, 
more recent Java, "what-PJ-doesnt-like" and what-not.) That one 
would, for now, probably only work perfectly on SUSE-10.2; but as 
soon as LSB 4.x is a common denominator, it will work on many more 
systems likewise...   :-)

>   Thorsten

I hope these explanations did help to remove some of the fog around
klik.

Cheers,
Kurt

-------------------------------------------------------------------
         1. "wget klik.atekon.de/client/install -O -|sh"
         2. "klik://openoffice"  to see the future *now*
-------------------------------------------------------------------