Re: Autopackage?

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent
thread

Re: Autopackage?
by Niall Walsh on Friday 16/Sep/2005, @05:12

The update system is to klik/install the latest version of any application you want.

You run the program from the cmg normally by clicking on it, typing the command name at the command line will use the normal system installed version. Your system is uneffected, only the application you have installed, when run from the cmg, will see any alterations.

Autopackage is completely different imho. Autopackage is still a normal system installation tool, klik is not. Klik is a complimentary technology to normal system installation tools/processes, which uses them to take care of the things they do best (dependencies) but provides an alternative way to use the information and software they hold.

Related Links

·   Articles on KDE Tweak of the Week
·   Also by Niall Walsh
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: Autopackage?
by Andreas Hennig on Friday 16/Sep/2005, @05:53

Correct me if I'm wrong, but klik seems to be more like Apple's Fat Binaries. A great solution for a specific problem (as in distributing testing / nightly versions of software in this case). It takes care of dependencies by putting all libs, but an agreed upon base set, in the package and you just stick it wherever you want and run it.

The aims of Autopackage are different/broader as it seeks to be a solution for distributing end user stable versions, without duplication of Libs and ultimately integrating it with the native distro package system be that tar.gz, deb, rpm or whatever else. It also a non-root user install locally and then informs the root user so he/she can install it globally if he/she thinks its pertinent. Actually those are just some highlights that I find important for me :) The Autopackage aproach is way more complicated, both to implement and to get working right, as there are, due to it's complexity, more points of failure. BUT... it solves a greater set of software distribution problems than klik.

My evaluation: Klik seems great for the job it was created (running testing/nightly builds on a tester/developer machine) THANKS GUYS. To install software on a non-testing machine, where things need to be installed globally, not duplicate lots of libs, allow easy updates & integrate well with the distro, there's Autopackage.

I have followed the Autopackage mailing list for many monts now and it is really exciting to see how they are solving the problems that crop up. Before I started reading the mailing list I had a vague idea that Linux Distros worked very differently and where using different incompatible versions of basic libs, but now that I see the guys at Autopackage solving so many things to be able to achieve their goal, (making relocatable binaries, dealing with different File structures and config systems, packaging systems etc) I see their efforts in a totally different light. It's a difficult task, but they have done very well so far.

Congrats on y'alls achievements with klik. It will make my complusive nightly testing and cutting edge feature admiring much easier ;)

Cheers,

Andreas
Montevideo, Uruguay

[ Reply To This | View ]

Re: Autopackage?
by Niall Walsh on Friday 16/Sep/2005, @06:08

Yes, it is more like an "Apple Fat Binary" then an autopackage.

I was unanaware (or had forgotten) that autopackage was usable by normal users to install software without administrative priveleges. I guess that puts klik and autopackage into "slightly" more competition which is never a bad thing :-) That being said, they address different needs, as you have pointed out, and have a fundamental difference, klik bundles dependencies and allows the "installation" of an application to have zero impact on your system (ok it might add a menu entry and maybe an icon to your system).

As I now understand it in user mode with autopackage the installation of one newer package could pull in updates which adversely imapct other software you have running. The flip-side is that autopackage can pull in underlying library updates which can see improvements in other applications. This is not trying to say klik is better then autopackage, just that they address different issues so comparisons can only really be made carefully. One updates a software system, the other simply makes programs available to run on a system. Horses for courses.

As I understand it if autopackage was successfully generally adopted by packagers , klik would have few if any problems using autopackages as the sources for it's cmg files.

[ Reply To This | View ]

Re: Autopackage?
by Andreas Hennig on Friday 16/Sep/2005, @07:30

I think you have explained it well, Autopackage is still in the process of solving certain issues (although it's very usefull already). And I agree with you on you last statement, I don't have a clue if the developers have thought about that, They might. I think it would be cool if it was possible for developers to easily create both types of packages simultaneously. That would be great. I think having both types of packages created and available for a software would be very profitable.

Cheers,

Andreas

[ Reply To This | View ]

Re: Autopackage?
by Zachary Jensen on Monday 19/Sep/2005, @06:48

"ok it might add a menu entry and maybe an icon to your system"

While I do not mind the addition of an icon or configuration files to my system, I find the menu entry a bit intrusive. While one can safely ignore the addition of an icon or configuration file, menu items are a different story. They are more difficult to remove (for end-users), particularly since klik doesn't have "uninstall" options. If the purpose is to avoid a "true" installation, then it shouldn't have a visible effect (when it isn't running)... Any behavior that is somewhat permanant is a "bug", IMHO.

Hence, I have a suggestion. Would it be possible to either:
A) Create a "subsystem" within KDE that automatically removes any "cruft" that this would add to the system (over time)? Eg. When I delete the klick package, it could automatically remove any .desktop items that point to it/etc.
B) Instead of adding menu entries, could it be integrated via plasmoids? (KDE 4) It would be great to have a plasmoid that stores your last N klick downloads. For KDE 3.5 this could be implemented by either putting icons on the dekstop, or creating a kicker applet).

I don't really know if either of the above solutions are implementable. However, if one of them (or something similar) would be implemented, this system would definitely be a nice complement to autopackage.

[ Reply To This | View ]

Re: Autopackage?
by Christian Loose on Friday 16/Sep/2005, @06:17

I agree with almost all you have said, but I wouldn't limit the scope of klik as much as you did. I think it's also interesting for end-users.

Just a few use-cases, where I think that klik would be useful:

a) You want to try-out a new version of an application without removing the current installation.
b) You want to try-out a new application but you want to make sure that you can remove it cleanly without disturbing the rest of the system.
c) You are on a multi-user machine and really want to use this one application that the sysadmin doesn't care about. :)

Besides the amount of duplicate libraries really depends on the definition of the base libraries. When you see Qt and kdelibs as part of the base system than the duplication is IMHO negligible.

[ Reply To This | View ]

Re: Autopackage?
by Quintesse on Friday 16/Sep/2005, @06:51

How about that application where nobody has bothered yet to make a package for?
Or just because it's so damn easy to click on a link and start using the app?

[ Reply To This | View ]

Re: Autopackage?
by Christian Loose on Friday 16/Sep/2005, @07:08

Of course! My list wasn't meant to be exhaustive. :)

[ Reply To This | View ]

Re: Autopackage?
by Andreas Hennig on Friday 16/Sep/2005, @07:16

You're totaly right... my comment was not so much about what klik can do... but rather about how Autopackage complements Klik or vise-versa.

Scenario 1. I am the Admin

I can even think of a situation where I would use klik to test, check out the feature set or just generally check out a new tool I am thinking of deploying, and then (assuming both klik and autopackages are available... would be nice) once I want to deploy it for the rest of the users, I'd just get an autopackage and install globally, which would give me a few other advantages (as mentioned in earlier post). Or get the rpm, deb or whatever the native package format is.

Scenrio 2. I am just Joe User (or Andi user in my case :)

I want to run a tool my Admin does not have available, and probably won't provide... I get the Klik package and I am done, or I can get the Autopacke which also works, BUT: More than likely though, with me being one of those guys who likes to carry everything with Him (yes, I got a notebook... but the battery is dead, the powersupply is dying, I live in South America and got married recently - i.e. I can't afford a new one), I'd just put the Klik package on my USB stick and carry the tool with me... ;) Can't do that with Autopackage...

So, really In my earlier post I was just trying to clarify some more the usage of Autopackage (which is what I know more about) and not as much to explore the multiple uses of Klik.

I think there is some overlap in possible usage cases, but I still think that they are sufficiently different that a developer might want to publish binaries of all builds (nightly, alpha, beta, rc and final) with Klik and then maybe only publish final builds or maybe beta, rc and finals with Autopackage. I believe it's definitely not an either - or type scenario, but rather a matter of using the right package type for the right job and/or target audience.

Cheers.

[ Reply To This | View ]

Re: Autopackage?
by Taj Morton on Friday 16/Sep/2005, @07:53

<blockquote>Can't do that with Autopackage...</blockquote>
You can create sealed installers with Autopackage, as well as stick the Autopackage support code on a USB drive, and then you have a stand-alone Autopackage. :)

Or maybe I completely missed what you meant. :)

--
Taj

[ Reply To This | View ]

Re: Autopackage?
by Andreas Hennig on Friday 16/Sep/2005, @09:20

Taj,

thanks for correcting me... that's exactly what I meant and I was wrong. That's why I sent a message to the Autopackage mailing list asking everyone to come over and join in the discussion, so the developers themselves would comment on Autopackage and correct any missrepresentation on my part.

Great to see you guys are joining in! You are the ones qualified to talk about Autopackage!! I just try and spread the word, though my understanding might not be complete.

Thanks!!

Andreas

[ Reply To This | View ]

Re: Autopackage?
by Andreas Hennig on Friday 16/Sep/2005, @09:40

[ Reply To This | View ]

Re: Autopackage?
by Andreas Hennig on Friday 16/Sep/2005, @10:05

[ Reply To This | View ]

Re: Autopackage?
by Taj Morton on Friday 16/Sep/2005, @07:50

Autopackage can do c). As for a and b, parallel-installs are slated for 1.1, but they're not implemented yet.

Patches welcome!

--
Taj

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"coffee? kde developers drink tea ;)" -- Dirk Mueller
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.