Attempt to extend yumpkg.py

40 views
Skip to first unread message

Duane Crouch

unread,
Apr 4, 2012, 9:25:05 AM4/4/12
to salt-...@googlegroups.com
In an attempt to try to extend yumpkg.py, The print gives similar output to what I was thinking but I could use a pointer.  http://thunked.org/p/view/pri/fed9ub2ap

Thomas S Hatch

unread,
Apr 4, 2012, 11:55:30 AM4/4/12
to salt-...@googlegroups.com
This looks good, and I would take it. Would it be possible to return a dict instead of a list though? that has key = package name and val = available version?

Duane Crouch

unread,
Apr 4, 2012, 12:03:33 PM4/4/12
to salt-...@googlegroups.com
Sure, I can return a dict, it just was not working properly, perhaps the reason on return value alone.  On line 10 (Output), [<YumAvailablePackageSqlite type in return was what I was leading to.  

I'll definitely work more on this.

Duane Crouch

unread,
Apr 5, 2012, 2:51:14 AM4/5/12
to salt-...@googlegroups.com
Thanks for the pointers.  That definitely pointed me in the right direction towards completion.  

Thomas S Hatch

unread,
Apr 5, 2012, 2:55:36 AM4/5/12
to salt-...@googlegroups.com
Nice, thanks Duane! This looks good, now we just need to get it to the rest of the package managers!

Devon Stewart

unread,
Apr 5, 2012, 3:53:36 AM4/5/12
to salt-...@googlegroups.com
Should be a fairly easy addition to apt.py, I'll see what I can do if it's not already in there.

-Devon

Devon Stewart

unread,
Apr 5, 2012, 5:39:24 AM4/5/12
to salt-...@googlegroups.com
Before I submit this pull request, can I suggest a name change to something like "list_upgradable" or similar? I'm coming in halfway, so not sure if this is named like this for a reason.

-Devon

Duane Crouch

unread,
Apr 5, 2012, 7:52:47 AM4/5/12
to salt-...@googlegroups.com
The only reason I named it that is as seen yum has a check-update, which covers that feature. apt has apt-get upgrade -s.  When testing I had check_upgrades, and changed the name.  It can be named anything, just thought that kind of named the feature similar to the manager.

You're very welcome Thomas.  Feels great to be able to contribute.  

Jeff Schroeder

unread,
Apr 5, 2012, 8:17:26 AM4/5/12
to salt-...@googlegroups.com
On Thu, Apr 5, 2012 at 4:52 AM, Duane Crouch
<duane....@mnxsolutions.com> wrote:
> The only reason I named it that is as seen yum has a check-update, which
> covers that feature. apt has apt-get upgrade -s.  When testing I had
> check_upgrades, and changed the name.  It can be named anything, just
> thought that kind of named the feature similar to the manager.

Would you mind using git and pushing a branch to github please? Also,
what do you think of the name list_upgrades() for the function? It
keeps the naming inline with a lot of the rest of salt. Good stuff.

--
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com

Duane Crouch

unread,
Apr 5, 2012, 9:21:19 AM4/5/12
to salt-...@googlegroups.com
I made a few changes (added comment structure for doc) removed other function I made, and changed the name to list_upgrades.  

Looking forward to pushing code.  On IRC now, if anyone is available I'll be there for a while, let me know which branch to push to.

Thomas S Hatch

unread,
Apr 5, 2012, 10:28:05 AM4/5/12
to salt-...@googlegroups.com
Yes, list_updates is better, thanks! When you do a github pull request it will use the default develop branch, so it should be easy!

Devon Stewart

unread,
Apr 5, 2012, 12:57:12 PM4/5/12
to salt-...@googlegroups.com
Ack, list_upgrades or list_updates? You and Jeff seem to have come up with different names.

Jeff, comments?

-Devon

Jeff Schroeder

unread,
Apr 5, 2012, 1:01:57 PM4/5/12
to salt-...@googlegroups.com
On Thu, Apr 5, 2012 at 9:57 AM, Devon Stewart <devo...@gmail.com> wrote:
> Ack, list_upgrades or list_updates? You and Jeff seem to have come up with
> different names.
>
> Jeff, comments?

Either of those is better than something yum specific. The merged
version ended up being "list_upgrades", which seems fine to me.
Intuititively, I think updates and not upgrades, but the distinction
is not relevant. So long as we come up with something generic and
vaguely intuitive (which duane's solution is), that is implemented
cleanly, I'm a happy camper.

Now we just need to add list_upgrades() to the other package modules.

Duane Crouch

unread,
Apr 5, 2012, 4:16:48 PM4/5/12
to salt-...@googlegroups.com

Not sure if this deserves a new topic or not, probably best in here.  I failed at applying the change in this thread across multiple servers, starting with the first one and stopping there.

After a few times of getting package not available error, I renamed yumpkg.py file to yumpkg.py, reloaded salt, restarted minion master, renamed salt modules directory and restored files.  Tried to uninstall and then install from rpm.  And from git.  No matter what I get the same ouput as mentioned here.  Not sure where to go from here.

Duane Crouch

unread,
Apr 6, 2012, 12:48:57 AM4/6/12
to salt-...@googlegroups.com
Thank you everyone for your help especially Thomas, he helped me a bit in emails.  I kind of overlooked this for a while, but as I was heading to sleep I saw yumpkg5 and thought maybe try that as the only system I tested this on that was not working was a Centos 5.8 system...

[root@salt-master modules]# salt 'salt-minion-5.8' sys.doc | less
[root@salt-master modules]# salt 'salt-minion-5.8' pkg.list_upgrades
{'salt-minion-5.8': None}
[root@salt-master modules]# salt 'salt-minion-5.8' pkg.list_upgrades
{'salt-minion-5.8': {'device-mapper-multipath': '0.4.7-48.el5_8.1',
                     'kpartx': '0.4.7-48.el5_8.1',
                     'ksh': '20100621-5.el5_8.1',
                     'popt': '1.10.2.3-28.el5_8',
                     'rpm': '4.4.2.3-28.el5_8',
                     'rpm-libs': '4.4.2.3-28.el5_8',
                     'rpm-python': '4.4.2.3-28.el5_8',
                     'wget': '1.11.4-3.el5_8.1'}}

Duane Crouch

unread,
Apr 6, 2012, 1:01:37 AM4/6/12
to salt-...@googlegroups.com
LOL google offered to translate my last response... :)

Reply all
Reply to author
Forward
0 new messages