The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Autopackage?
by Kurt Pfeifle on Friday 16/Sep/2005, @05:11
|
### "Is there an update system integrated?"
----
No. You'll have to look yourself for updates.
However, some of the latest packages include version numbers in their names. So it would be easy to "install" (it is just copy, really) the "krita-1.4.88.cmg" side by side with "krita-1.4.0.cmg" and "krita-2005.17.09.cmg" and even run all 3 in parallel.
### "If I can install >20 packages I am not able to look after updates, especially if I am a normal user!"
----
May be true.
However, my own idea about klik is to use it primarily as a very efficient tool to help experienced users to testdrive development versions of KDE packages without them needing to compile themselvs, and without the distro packages needing to provide weekly snapshot RPMs and .debs (which they don't do, anyways).
Let's see how the idea is accepted. If it gets enough support, someone may even think of hacking the Makefiles so that there is a "make cmg" target available for everyone who compiles KDE apps on his own host.
### " What is, if the installed version replaces an old, system wide installation?"
----
A klik .cmg file never replaces an installed old, system wide software. It is there as an alternative.
You can run the system wide installed app side by side with the klik version. (The only conflict you may need to watch out for is that both may write into the same $HOME/.yourapp and $KDEHOME/somewhere files and directories with conflicting content...
### "Which version will be used?"
----
klik may have put its apps into your K menu. But even there it does not replace the installed app's entry. To the system, it looks like a separate app.
|
[
Reply To This | View ]
|
Re: Autopackage?
by Mario Fux on Friday 16/Sep/2005, @06:29
|
Great article and great tool, thx. I'm kliking ooo2 ;-).
But I think the problem with applications writing to the same config files could become a real problem for some persons.
Anyway, great tool, but how do I uninstall it?
|
[
Reply To This | View ]
|
Re: Autopackage?
by Kurt Pfeifle on Friday 16/Sep/2005, @07:02
|
### "great tool, but how do I uninstall it?"
----
Why should you ever want to uninstall it in the first place? ;-P
Seriously: to get rid of everything klik installed (including possible K menu entries), running these commands should accomplish it:
rm $HOME/{.klik,.zAppRun} \
$HOME/Desktop/*.cmg \
{$KDEHOME,$HOME/.kde}/share/services/klik.protocol \
{$KDEHOME,$HOME/.kde}/share/applnk/klik/{klik.desktop,.directory} \
{$KDEHOME,$HOME/.kde}/share/mimelnk/all/cmg.desktop \
{$KDEHOME,$HOME/.kde}/share/applnk/.hidden/AppRun.desktop \
rm -rf /tmp/{app,klik}
Last, edit /etc/fstab to remove the /tmp/app/{1,2,3,4,5,6,7} mountpoints.
Cheers,
Kurt
|
[
Reply To This | View ]
|
Re: Autopackage?
by jameth on Friday 16/Sep/2005, @08:03
|
> ### "Is there an update system integrated?"
> ----
>
> No. You'll have to look yourself for updates.
Would it be possible to integrate this system with the GetHotNewStuff system? If I remember correctly, that is set up to allow for a central server that shows versions of files and everything so that the end user can see, in a list, what is already installed on their system, what is installed on their system and could be updated, and what is not installed on their system at all.
Of course, I haven't particularly used GHNS of Klik, so I wouldn't have any idea what I'm talking about, but I much prefer the idea of Klik if it makes not only installing, but also updating as easy as clicking a button. Also, I'm always a fan of reusing technologies, so...
|
[
Reply To This | View ]
|
Re: Autopackage?
by superstoned on Friday 16/Sep/2005, @15:48
|
I think it's a good idea, and i've used both :D
yeah, i think it should work. maybe this is the solution to the problem of c++ applets/plasmoids... and to the problem of installing kde applications. I think, and some others do so to, kde itself should be smaller, and the additional applications should be installable easilly. if possible with an KDE interface.
|
[
Reply To This | View ]
|
|
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.
|
[
Reply To This | View ]
|
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 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
|
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, @10:05
|
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 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 ]
|
|
Re: Autopackage?
by a.c. on Friday 16/Sep/2005, @16:15
|
It would be nice to see the packaging tool create a torrent file, and an RSS file. Then when adding a klik, it can be registered in a DB with the RSS url. When needed, it simply torrents it down. In fact, the tool could be set-up to do autodownload (nice for nightly downloads) with the use of torrents (but the file could be palced in a different directory until the user has had time to approve the install). That way, most of the downloads occur in the first night (lots of systems to work with).
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
