Well, PackageKit is a nice gui to use with upkg.

Here are some snippet out of the conversation I had with the lead-developer of that tool:

Zitat

<hughsie> amnon: the best thing you can do is look at the developer documentation here: http://www.packagekit.org/pk-help.html <hughsie> amnon: do you have a python or c binding? <amnon> upkg is a mono vala build ... <hughsie> amnon: we've never had a mono-based language helper <hughsie> amnon: but it should be easy enough to hook up <hughsie> amnon: you probably want to read: http://www.packagekit.org/pk-reference.html <hughsie> and then email the list with a list of questions <hughsie> amnon: it's better if you use a native binding, although you can just use an executable if you want <hughsie> amnon: a native binding gives you percentage updates and stuff liek that ... <amnon> upkg is an executable. <hughsie> amnon: how do you get percentage updates of a transaction? <amnon> well juergbi thinks packagekit will work better with upkg2. It will be more deb-like ... <hughsie> amnon: well, you can make it work <hughsie> amnon: but it's better when we have internal knowledge to the tool <hughsie> amnon: when you do, checkout backends/box/ <hughsie> amnon: i only have a limited amount of hacking time :-) <amnon> np. ... <hughsie> amnon: you can use pkcon for testing <amnon> the box-thing is the right way to test it. I've only to edit the scripts. <amnon> I'm in the install-file.sh atm and see this line: box -i "$pkg" 2>&1 >/dev/null <hughsie> amnon: sure, but you'll get a pretty "dumb" backend type <hughsie> amnon: because there is no extra info other than "it finished" <hughsie> the conary backend reports what it's doing so the gui can update and icons can change <amnon> so it is the cmdline of box. If I replace it with mine. <amnon> so box is only an example <hughsie> amnon: no, it's a working backend, there's just better ways to do it <hughsie> amnon: you can use threads like the apt.old backend <hughsie> amnon: or used spawned script files like the yum, backend ... <hughsie> amnon: well, if you are in a position where you can change the tool there are two things you can do for a kick-ass packagekit backend <hughsie> amnon: write another shim tool upkg-pk that emits stuff like "percentage<tab>10" for packagekit to capture <hughsie> amnon: or just write a nice library that we could use in a threaded backend in native C/c# <hughsie> amnon: if you see http://www.packagekit.org/pk-reference.html#backends-spawn-common <hughsie> amnon: you can see that the output is actually quite easy and low tech <hughsie> the packagekit daemon does all the cleverness <amnon> thx for the tips <hughsie> amnon: no problem - i need to do some work now, but email the list if you need anything cleared up <hughsie> amnon: the other guys know the plan <amnon> what other guys? <amnon> so we have to create a helper which creates and takes these cmds to get it work <hughsie> ohh, the other packagekit dudes

Seems to be a nice guy and I and Juerg thinking packagekit is the right choice. What do you think?

Should I dig deeper in this manner or do we add packagekit support soon to an upcoming upkg-release?

I don't think that upkg is ready for using packagekit because if you take a look at the interface of packagekit, http://www.packagekit.org/img/gpk-application-search.png, you'll see that there are places that will be missing because of upkg specs that have been written... I mean... our specs now don't provide the informations for a pleasent PK interface... we still miss groups, better organization of the packages acording to any criteria, and also we have packages with too minimum description which would make not so pleasant interface when reading what the package is meant to be...

In short for packagekit I think we still miss better specs... when the specs gets more complete then I guess packagekit will be the next implementation...


 
..............................
OSs: Paldo-testing x86_64 :: HP Pavilion dv9680ez

i agree with diogo about specs, but i believe this can not be a reason for canceling usage of packagekit as a gui which is really required for unexperienced users. but upkg needs some tools to repair itself , u know sometimes it stucks and u need to remove /var/cache folder by yourself e.g.

Jürg told me that upkg2 should have packagekit support.
When we start developing upkg2 I don't know. Jürg and Raffaele
wanted to start it maybe later this year, but is only
my suggestion.

Shure a repair-function is needed. rm -rf /var/cache/upkg/*
is from time to time needed.

With time we will see ...

Just out of curiosity, I'v been using paldo testing for 6 months now and its been 4 or 5 months that I haven't removed the /var/cache/upkg... I constantly use upkg for upgrading, creating specs and etc... Why haven't I needed to remove /var/cache/upkg and people claims it is needed from time to time...?
 
..............................
OSs: Paldo-testing x86_64 :: HP Pavilion dv9680ez