KDE OS: Why not

[Robert Knight]

Hello,

Going from what Kurt said I think Klik has a very important advantage
over Autopackage - because it doesn't "mess with the base system" I
think it is a much easier sell for integration into the distributions.
 For anything like this to be accepted, support at the distro level is
absolutely paramount.
In my experience installing the Klik client has also been more reliable.

In the early days of Autopackage, the author of the project (Mike
Hearne) wrote some very unkind things about the way desktop Linux
currently works.  Of course there was some truth in his comments (
emphasis on "some" ), but I think some "bad blood" still lingers.

Regards,
Robert.

On 05/01/07, Kurt Pfeifle <k1pfeifle at gmx.net> wrote:
> 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
> _______________________________________________
> kde-quality mailing list
> kde-quality at kde.org
> https://mail.kde.org/mailman/listinfo/kde-quality
>