faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
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. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
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 ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
