[packagekit] Improved pkt tool

[Ken VanDine]

I was thinking it could call get-updates with some extra data, like
repo to use.  Then it would show up in the updates dialog.  conary
does work like other systems, it has very strong affinity.  So unless
you tell it to actually change labels, it won't.  So changing the repo
to look for updates on doesn't help.  I think this fits well with get
updates, perhaps allowing an option argument which tells it to do
something different.  In conary lingo, I would say something like
"get-updates.py toplevel group-dist=foresight.rpath.org at fl:2"

Of course we should make that more generic, probably use package_id style.

--Ken

On 9/7/07, Richard Hughes <hughsient at gmail.com> wrote:
> On Fri, 2007-09-07 at 10:10 -0400, Ken VanDine wrote:
> > That is what i generally use too... pcon is very useful.   However, I
> > love pkt.py as an example python interface.  I will need to write a
> > few of these for very specific uses, so having a good example is very
> > nice.  Even better would be to create a PackageKit-python api, really
> > making it easy to create external apps to interface with PackageKit.
>
> Sure, that's not a bad idea. I'm no python dude, but it sounds a good
> idea for bolt on stuff.
>
> > Some examples of things I plan to work on:
> >  * Hardware monitor, hal sees a device plugged in, call PK to install
> > the driver (if needed)
>
> HAL calling into PK, might work, although I would argue just install the
> driver anyway....
>
> >  * Distro major version upgrades, going from FL 1 to FL 2 will be
> > switching labels, so calling PK to update to
> > group-dist=foresight.rpath.org at fl:2
>
> On first thought, I'm not sure changing the backend config options
> through PK is a good idea.
>
> Maybe we could open-code it such that:
>
> SetBackendOption(s=data_string)
>
> data_string:
> "enable repo development:
>
> and let the backend do the decoding. Unfortunately that means having
> policy (PolicyKit action) stuff as well.
>
> I suppose that repo management could be abstracted nicely too, although
> this is all starting to feature creep.
>
> as=GetRepos()
> ChangeRepoState(s,b)
> ChangeRepoData(s,s)
>
> Comments and opinions welcome.
>
> > The distro upgrade tool will probably be something that runs at
> > startup but doesn't display an icon.  It will just monitor an rss feed
> > to see if it should suggest and update.  When it sees a major upgrade,
> > it will call PK to do the work and let the user confirm it.  These are
> > the types of upgrades that don't happen very often, but require some
> > extra info to perform.
>
> The likes of fedora and ubuntu also need this, so it would make sense to
> add this tool in some form into PackageKit. What sort of UI and
> interface were you thinking of?
>
> Richard.
>
>
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit
>


-- 
Ken VanDine
http://ken.vandine.org