Colin Walters wrote:
Another problem is that yum install and pkcon dont have the same features.2008/10/4 Tim Lauridsen <tim lauridsen googlemail com>:Hmmm. 1. yum-cli -> yum-api -> pk-con -> pk -> DBUS -> pk-backend -> yum-backend -> yum-api -> install the package compare to 2. yum-cli -> yum-api -> install the packageYou could also use the python dbus bindings directly, or python bindings for libpk.here is kind og chicken and egg problem here.There's no chicken-egg - the patch would look like this: if 'DBUS_SESSION_BUS_ADDRESS' in os.environ: if cmd == 'install': execv(['pkcon', 'install', sys.argv[1:]]) elif cmd == 'search': execv(['pkcon', 'search', 'name', sys.argv[1:]) # ..and maybe a total of 3-4 more commands. Personally, I only use those two.take this user case. ssh to some server yum install foo how would that work.With a change like the above, it would be unaffected, at least for now.Dont forget that PackageKit is a highlevel abstraction to the low level package management system, making the low level system use the highlevel abstraction of it self, is kind of crazy. IMHO.The (first) lower level system is yum-api, yum-cli and pkcon are really at the same level. It would make sense long term to having them be more merged.
yum install foo\* bar\* --enablerepo=rawhide --disableplugin=forbar --exclude=kernel\*
how do you what to do that in pkcon ?
It is like letting 'OpenOffice' call 'vi'.
pkcon is not a full blown package manager cli, it is a cli tool to do call the PK api, it need a lot of extra voodo magic to a full blown cli and i to think this is the idea of pkcon.
if you what to use 'pkcon install foo' then type it, and if you want to use 'yum install foo' then type that, like you would type 'vi' to use 'vi' and not 'openoffice'.