On 6/27/05, seth vidal <skvidal@xxxxxxxxxxxx> wrote: > > On Wed, 2005-06-15 at 22:11 -0500, Christopher Weis wrote: > > Okay, this time I built the patch against yum-2.3.3 as included in the > > yum-2.3.3-1.src.rpm package from Duke. After installing and > > configuring (making sure to add "tsflags=repackage" to /etc/yum.conf) > > I was able to do a "yum update" that created repackaged RPMs > > in /var/spool/repackage. > > > > If this proves to be a decent solution, we'll want to update the man > > page to reflect this new flag (see attached/proposed yum.conf.patch > > file). > > > > Thanks everyone. I'll keep an eye on the list for any bugs that are > > found with this. > > > > So I'm looking at this patch and I'm trying to figure out what it > actually _does_. > > It seems like you just added 'pass' for all the RPMCALLBACK_REPACKAGE_* > cases in the rpm callback. Shouldn't we be outputting _something_ so the > user knows the repackaging is going on? If only b/c repackaging could > take a while and it looks a bit odd that nothing is being outputted > during this time. > > What do you think? > > -sv Sorry for the long delay in getting back. I totally agree that process status needs to be shown, but I didn't even attempt it because I still don't get why the callbacks are called as they are when repackaging. From my original email... """ One of the many things I still don't understand about Yum/RPM: when repackaging a given package, RPMCALLBACK_REPACKAGE_START and RPMCALLBACK_REPACKAGE_STOP are set as expected, but RPMCALLBACK_REPACKAGE_PROGRESS is only set for one callback, after which RPMCALLBACK_INST_PROGRESS is set for the rest of the repackaging progress callbacks. """ I would expect RPMCALLBACK_REPACKAGE_PROGRESS to be set multiple times so that a progress message can be output to the user, just as it's done when RPMCALLBACK_INST_PROGRESS is set, but from what I can tell, it is consistently set for only one callback. This seems very wrong to me. I guess I could set some kind of a flag on RPMCALLBACK_REPACKAGE_START, unset it on RPMCALLBACK_REPACKAGE_STOP, and make the RPMCALLBACK_INST_PROGRESS handler do the appropriate work based on this flag, but that's just plain ugly. Perhaps this is a case of the callback "caller" not setting the appropriate RPMCALLBACK_REPACKAGE_PROGRESS bits? Anyone have any ideas? I'll keep digging to see if I can figure out what's causing the confusion, which may quite possibly lead to my own ignorance. :-) Thanks. ~Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.dulug.duke.edu/pipermail/yum/attachments/20050720/a3a684d7/attachment.htm
