KDE OS: Why not

[Kurt Pfeifle]

On Friday 05 January 2007 10:41, Chris wrote:
> Am Freitag 05 Januar 2007 05:20 schrieb Kurt Pfeifle:
> > More and more people come to realize that this is a problem that
> > needs to be tackled. Hence the recent LSB face to face meeting in
> > Berlin that discussed "packaging" (December 6 2006, according to
> > http://www.freestandards.org/en/LSB_face-to-face_%28December_2006%29 )
> 
> Those interested in that topic (and I think most developers and ISVs *should* 
> be) there is also autopackage:
> 
> http://www.autopackage.org/
> 
> It's somewhat like klik

No, klik and autopackage are very much different (though working for 
the same goal).

- autopackage builds binaries + compiles from sources.
- klik repackages pre-compiled packages (.rpm, .deb, .tgz or even 
  auto-.package)

- autopackage "messes" with the base system (/usr/{lib,bin}/*)
- klik does not touch the base system

- autopackages are not necessarily relocateable, and they install
  into the system environment where "normally" the native package
  manager resides (and they may confuse him quite severely); though
  I understand this will be fixed sometime in the future.
- kliks are relocateable; you can run them from anywhere, even from
  a USB stick or a CD-RW. (I have private klik bundles complete with 
  Wine,Internet Explorers 5.0, 5.5 + 6.0, and some other proprietary
  Win32 software that run from a DVD for all Linux installations in
  my reach -- but they can't be redistributed for obvious license 
  reasons).

- it is fairly difficult to create an autopackage for an application
  where there is not yet one (effort to be spent may be some hours
  up to several days of work).
- it is very easy to create a klik recipe for an application where
  there is not yet one (effort for a new recipe typically is 1-2
  minutes; in exceptional cases 1 hour).

- autopackages are currently available for no more than maybe 50 
  different applications (please do tell me if I am wrong).
- kliks are available thousands of applications.

That said, we (klik developers) very much appreciate what the auto-
package developers have achieved in terms of overcoming and working
around the &%*#*?! binary incompatibilities created by gcc and glibc
development decisions. They have developed quite a few tools and
standard procedures which should be followed and used by *anyone* 
who builds packages (for any distro). We would very much like to 
see some of their achievements be adopted by other packagers. We
would love to base all of our klik recipes on .package ingredients

> in the way that it yields installer-like packages you  
> can use on almost any recent linux distribution. Actually from my experience 
> as a user of both autopackage and klik it is more mature

Yes, I agree:

- autopackage is "more mature" (for those few applications where a 
  .package exists, it works pretty much for 100% of users and distros)
- klik is less mature, and only "usable alpha" quality. "Usable" here 
  meaning: if it works for a user and his distro, it works very well.
  "Alpha" here meaning: we've not yet implemented all the features 
  we'd like to have in klik; 

A huge part of those cases where klik does not yet work (a certain 
percentage of recipes fails for a certain percentage of users/distros),
this will be overcome by
  -- fixing recipes (needs more volunteers -- being a "power user" who
     is willing to learn some Bash scripting is enough, no need for a
     "real" programming language)
  -- more widespread adoption of LSB 3.x and 4.x (and a "good enough"
     definition of LSB for desktops) so that klik can make solid 
     assumptions about the base system environment its package has to 
     work in.

Cheers,
Kurt