hi guys,
anyone fancy a shot at writing a yum plugin that would change the yum update behavior a bit.
what I'd like to end up with is that if in a yum update process, there is an update to yum itself - that yum update should run first, once done, yum should then restart and run through the rest of yum update.
- K
Karanbir Singh napsal(a):
hi guys,
anyone fancy a shot at writing a yum plugin that would change the yum update behavior a bit.
what I'd like to end up with is that if in a yum update process, there is an update to yum itself - that yum update should run first, once done, yum should then restart and run through the rest of yum update.
- K
Well, plugin to remove all packages but yum, if yum is within updated packages, is easy to write. But plugin can only stop yum execution and I can't see way to run yum again after yum update by itself. What is the purpose of that plugin? David
David Hrbáč wrote:
what I'd like to end up with is that if in a yum update process, there is an update to yum itself - that yum update should run first, once done, yum should then restart and run through the rest of yum update.
plugin to remove all packages but yum, if yum is within updated packages, is easy to write. But plugin can only stop yum execution and I can't see way to run yum again after yum update by itself. What is the purpose of that plugin?
Hi David, thanks for picking up on this.
Just displaying a message will be enough for now - if the process can exit with a 'yum has been updated, you need to now run yum again in order to process the other updates' - that should be fine, i think.
purpose of the plugin is to fix an issue with yum itself, where it breaks into bits when there is functionality changes in a yum update, and can leave other packages in a not-completely-installed state.
in specific terms, the issue we have is updating yum 2.0 to yum 2.4 / 2.2 where there is a change in the way kernel packages are installed. If yum is updated along with a new kernel package - the kernel package isnt installed properly.
And besides this, I think packages in a repository should be able to assume the functional process of the package manager included in the repository.
El vie, 11-08-2006 a las 16:54 +0100, Karanbir Singh escribió:
hi guys,
anyone fancy a shot at writing a yum plugin that would change the yum update behavior a bit.
what I'd like to end up with is that if in a yum update process, there is an update to yum itself - that yum update should run first, once done, yum should then restart and run through the rest of yum update.
- K
Hi Karan,
Don't know how are you folks in that plugin state but if this can be useful... feel free to pkg and try it or use it if it's what you expected. First approach, new with pyton, new with yum... 2 be tested.
Jose.
On Sat, 12 Aug 2006, David Hrbá�~M wrote:
Karanbir Singh napsal(a):
what I'd like to end up with is that if in a yum update process, there is an update to yum itself - that yum update should run first, once done, yum should then restart and run through the rest of yum update.
Well, plugin to remove all packages but yum, if yum is within updated packages, is easy to write. But plugin can only stop yum execution and I can't see way to run yum again after yum update by itself.
I don't see why yum couldn't update yum, then exec the new yum program, listing the remaining packages as install arguments. You'd need to unlock the lock file before calling execve.
--- Charlie
I don't see why yum couldn't update yum, then exec the new yum program, listing the remaining packages as install arguments. You'd need to unlock the lock file before calling execve.
But IMHO that wouldn't be very pretty, it would be nicer if a plugin could trigger a jump back in the processing chain.
-- Daniel
Charlie Brady wrote:
Well, plugin to remove all packages but yum, if yum is within updated packages, is easy to write. But plugin can only stop yum execution and I can't see way to run yum again after yum update by itself.
I don't see why yum couldn't update yum, then exec the new yum program, listing the remaining packages as install arguments. You'd need to unlock the lock file before calling execve.
no! yum, on re-entry, needs to re-parse the metadata - its possible remote end metadata has changed for the new yum as well.
On Sun, 13 Aug 2006, Karanbir Singh wrote:
Charlie Brady wrote:
Well, plugin to remove all packages but yum, if yum is within updated packages, is easy to write. But plugin can only stop yum execution and I can't see way to run yum again after yum update by itself.
I don't see why yum couldn't update yum, then exec the new yum program, listing the remaining packages as install arguments. You'd need to unlock the lock file before calling execve.
no! yum, on re-entry, needs to re-parse the metadata - its possible remote end metadata has changed for the new yum as well.
For a while I couldn't see what you were saying "no!" to - certainly my assertion about the lock file is true.
OK, so you want the first yum to exec a new yum with the same arguments that it itself was called with. It will then calculate its own transaction set.
Hopefully it will not itself try to replace itself with the old yum package.
--- Charlie
Charlie Brady wrote:
Charlie Brady wrote:
Well, plugin to remove all packages but yum, if yum is within updated packages, is easy to write. But plugin can only stop yum execution and I can't see way to run yum again after yum update by itself.
I don't see why yum couldn't update yum, then exec the new yum program, listing the remaining packages as install arguments. You'd need to unlock the lock file before calling execve.
no! yum, on re-entry, needs to re-parse the metadata - its possible remote end metadata has changed for the new yum as well.
OK, so you want the first yum to exec a new yum with the same arguments that it itself was called with. It will then calculate its own transaction set.
yes :)
Hopefully it will not itself try to replace itself with the old yum package.
humm ? after the yum package has updated, there really should be no hint of the old yum stuff.....
On Sun, 2006-08-13 at 12:13 +0100, Karanbir Singh wrote:
Charlie Brady wrote:
Charlie Brady wrote:
Well, plugin to remove all packages but yum, if yum is within updated packages, is easy to write. But plugin can only stop yum execution and I can't see way to run yum again after yum update by itself.
I don't see why yum couldn't update yum, then exec the new yum program, listing the remaining packages as install arguments. You'd need to unlock the lock file before calling execve.
no! yum, on re-entry, needs to re-parse the metadata - its possible remote end metadata has changed for the new yum as well.
OK, so you want the first yum to exec a new yum with the same arguments that it itself was called with. It will then calculate its own transaction set.
yes :)
Hopefully it will not itself try to replace itself with the old yum package.
humm ? after the yum package has updated, there really should be no hint of the old yum stuff.....
You could also put a shell or python wrapper around yum for this thing if you wanted to:
parse the arguments on the cli and see if it is just running 'update' for all packages w/o looking for any other specific thing. If so then first run a yum update yum. If that completes successfully then run the rest of the update.
that might be easiest, actually.
-sv
Karanbir Singh napsal(a):
Hi David, thanks for picking up on this.
Just displaying a message will be enough for now - if the process can exit with a 'yum has been updated, you need to now run yum again in order to process the other updates' - that should be fine, i think.
purpose of the plugin is to fix an issue with yum itself, where it breaks into bits when there is functionality changes in a yum update, and can leave other packages in a not-completely-installed state.
in specific terms, the issue we have is updating yum 2.0 to yum 2.4 / 2.2 where there is a change in the way kernel packages are installed. If yum is updated along with a new kernel package - the kernel package isnt installed properly.
And besides this, I think packages in a repository should be able to assume the functional process of the package manager included in the repository.
Hi Karanbir, the plugin is working, but not with yum in CentOs. :o) In yum-2.4.2-2.centos4 there is not implemented remove method in file transactioninfo.py(7 lines of code in CVS). Plugin works pretty well, if yum is in packages to update, all packages are removed from transaction but yum and dependecy is resolved finally. Resolving is mandatory, a new yum can have different dependency. What we are going to do now? Regards, David
David Hrbáč wrote:
Hi Karanbir, the plugin is working, but not with yum in CentOs. :o) In yum-2.4.2-2.centos4 there is not implemented remove method in file transactioninfo.py(7 lines of code in CVS). Plugin works pretty well, if yum is in packages to update, all packages are removed from transaction but yum and dependecy is resolved finally. Resolving is mandatory, a new yum can have different dependency. What we are going to do now?
can we just backport the function ?
also, have you looked at the code that JJ Garcia sent in ?
Karanbir Singh napsal(a):
can we just backport the function ?
Yes, we can. I have thought CentoOS is not changing packages coming from upstream. So, we need to patch /usr/lib/python2.3/site-packages/yum/transactioninfo.py, see http://devel.linux.duke.edu/cgi-bin/viewcvs.cgi/yum/yum/transactioninfo.py?r.... Look at remove method. I'm sending patched file.
also, have you looked at the code that JJ Garcia sent in ?
Yes, I have. We should go different way. We will use exclude_hook finally, but not now.
To sum it up. The code I'm sending, is really pre-alfa. Because I have tested it on machines where yum is updated, code work with iftop, which has been updated by Dag a few days before. You can change in yumfirst.py: yumname = 'iftop'
Plugin works pretty fine: yum update yum install expect iftop Both command are run and only iftop is installed/updated.
The plugin should be extended to work event in those cases: yum install expect yum update expect And here comes exclude_hook.
So, give it a try and if it's ok, I'm gonna extend the functionality. David
[main] enabled=1
David Hrbáč wrote:
Karanbir Singh napsal(a):
David Hrbáč wrote:
can we just backport the function ?
Karanbir, have you tested my plugin?
I've been tied up with the 4.4 stuff in the last couple of day, I'll be able to look this weekend. In the mean time, someone else should have already tried this out ? feedback ?
On Sun, Aug 13, 2006 at 09:30:31AM -0400, seth vidal wrote:
You could also put a shell or python wrapper around yum for this thing if you wanted to:
That's what we do at BU.
parse the arguments on the cli and see if it is just running 'update' for all packages w/o looking for any other specific thing. If so then first run a yum update yum. If that completes successfully then run the rest of the update. that might be easiest, actually.
It's also safer -- does the plugin handle the case where something yum depends on is being updated (or added) too?
Karanbir Singh napsal(a):
I've been tied up with the 4.4 stuff in the last couple of day,
OK
I have finished the plugin meanwhile. Is there somebody to test? Please edit file yumfirst.py and set variable yumname to some package you want to test with. During the test I'm using yumname = 'iftop'.
Plugin works only with yum running commands 'install', 'update', 'upgrade', 'groupupdate', 'groupinstall'. Handles dependency in case yum is to update itself.
Files are here: http://homen.vsb.cz/~hrb33/yumfirst/ David Hrbac
Hi Matthew,
Matthew Miller wrote:
On Sun, Aug 13, 2006 at 09:30:31AM -0400, seth vidal wrote:
You could also put a shell or python wrapper around yum for this thing if you wanted to:
That's what we do at BU.
share some code ?
On Thu, Aug 17, 2006 at 10:17:19PM +0100, Karanbir Singh wrote:
You could also put a shell or python wrapper around yum for this thing if you wanted to:
That's what we do at BU.
share some code ?
It's not beautiful. :)
ftp://linst.bu.edu/stormy/SRPMS/bulinux-autoupdate-1.1.3-bu46.1.src.rpm
We've been working, on the back burner, on doing something more pythony and less shellscripty, but what we've got works pretty well.
Karanbir Singh napsal(a):
hi guys,
anyone fancy a shot at writing a yum plugin that would change the yum update behavior a bit.
what I'd like to end up with is that if in a yum update process, there is an update to yum itself - that yum update should run first, once done, yum should then restart and run through the rest of yum update.
- K
I have created ticket. http://bugs.centos.org/view.php?id=1455 Regards, David
David Hrbáč napsal(a):
I have created ticket. http://bugs.centos.org/view.php?id=1455 Regards, David
I have created rpm package. http://homen.vsb.cz/~hrb33/el4/hrb/stable/i386/SRPMS/repodata/repoview/yum-p...
Package doesn't include patch to transactioninfo.py. Patched file is available to download at http://homen.vsb.cz/~hrb33/yumfirst/transactioninfo.py
Regards, David