faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Plasmoid packages
by dario on Monday 18/Jun/2007, @12:01
|
> just as kicker applets are and, in the future, plasmoids will be.
Excellent!
> what would you suggest are the strong points to learn from?
I was thinking of a) a trusted repository like the Mozilla Addons site (which Plasma will also have, as you mentioned in the other thread), b) a notification of when updates are available (which again Plasma will also have), and c) a straightforward way of installing/removing plasmoids (which I am sure is also in your plans). In fact, you seem to have everything already covered! Moving on...
> we do support versioning of the packages, however,
> so we could offer update notifications
Yeap, that would be very useful, particularly for those plasmoids that the user has privately installed, ie, those that are not system-wide.
But consider that the update mechanism will have to distinguish between packages that are installed system-wide and those that are privately installed. Just imagine the following situation:
There is a "Foo 1.0" system-wide plasmoid installed, and the user has a private installation of "Bar 1.0" (there are no dependencies between the packages). Now, a new version 2.0 is released for both Foo and Bar. The plasmoid updater will of course notify the user that the new versions are available. In the case of Bar, upgrading is straightforward, but what to do with Foo? One option would be for the plasmoid updater *not* to upgrade and instead to inform the user that they should use whatever mechanism is available in their distro to perform a system-wide upgrade. This has the disadvantage that the distro's update for the Foo plasmoid could take a while before it is available from their repositories. Another option would be for the plasmoid updater to upgrade anyway, installing version 2.0 of Foo as a private installation (which supersedes the system-wide package). But then you have the question of what happens when the system-wide package is also upgraded: will you end up with two copies of the same package, or will the plasmoid updater be smart enough to remove it when no longer needed? |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Plasmoid packages
by Aaron Seigo on Tuesday 19/Jun/2007, @09:48
|
i've actually thought about the issues you bring up in your last paragraph. for now, i'm punting on it but will revisit it for 4.1. it is a non-trivial problem, but we do have all the pieces we need to create a proper solution so i'm not worried. it's just doing the rather detailed work.
right now i'm concentrating on getting the Big Basics together for 4.0... the cuter stuff, like managing differences between local and system wide installs of plasmagik updatable packages, will come after that
|
[
Reply To This | View ]
|
Re: Plasmoid packages
by dario on Tuesday 19/Jun/2007, @13:15
|
> it is a non-trivial problem
Indeed. And it gets all the more non-trivial once you start taking package dependencies into account... But anyway, you are right that it is perhaps a bit too soon to be worrying too much about it.
But when that time does come, be sure to have a chat with the Debian guys about this issue; I wouldn't be surprised if they had already encountered it and given it a lot of thought...
|
[
Reply To This | View ]
|
Re: Plasmoid packages
by Aaron J. Seigo on Wednesday 20/Jun/2007, @20:39
|
dependencies are pretty much a non-issue. we're talking about leaf-node add-ons here.
|
[
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)
