Bug 4931

Summary:	some parts of updates should be done at the end
Product:	Mageia	Reporter:	AL13N <alien>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED INVALID	QA Contact:
Severity:	minor
Priority:	Normal
Version:	Cauldron
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:		CVE:
Status comment:
Attachments:	urpmi update

Description AL13N 2012-03-13 20:57:55 CET

I donno if filetriggers is the way for this, and I don't know if everything would work like this, but here it goes:

attached is a logfile of an update output, not excessively large, but still...

some parts of it, i think could be done at the end, and possibly another progress bar for ending parts(filetriggers?) could be done as well (in urpmi as well as rpmdrake):
 - initrd rebuilds
 - vboxadditions rebuilds
 - "Migrating sysvinit service 'httpd' to systemd native unit 'httpd.service' for target 'multi-user.target'"
 - restarting/reloading services
 - "Warning: Unit file of created job changed on disk, 'systemctl --system daemon-reload' recommended."
 - dkms builds and removal after kernel parts


if you look at the log, you'll see that there's a failed build (and i can only assume it was due to the related packages not yet installed...), i can only hope that it got fixed anyway and that rebooting will still work...

so, i'd be nice if all this happened at the end, and had some sort of progress bar with it.

if a filetrigger would fail, it would be nice for it to remember failing and retry next time, or even perhaps a manual command to list or rerun failed filetriggers at a later time...

Comment 1 AL13N 2012-03-13 20:58:25 CET

Created attachment 1753 [details]
urpmi update

Manuel Hiebel 2012-03-13 21:58:57 CET

Assignee: bugsquad => thierry.vignaud

Comment 2 Thierry Vignaud 2012-03-13 22:29:01 CET

That has nothing to do with urpmi.
urpmi order packages according to their requires, conflicts & suggests tags.
The build one was a incompatibility of virtual box with kernel-3.3 which has been fixed in virtualbox-4.1.8-4.mga2

Status: NEW => RESOLVED
Resolution: (none) => INVALID

Comment 3 AL13N 2012-03-13 22:50:23 CET

no need to close this...

this bug isn't because of that build that failed... that's not the point here.

the point is, this would be nice if stuff like this happened completely at the end, instead of in between. like filetriggers, AND to have some sort of progress bar related to those filetriggers, if possible.

the idea would be to have all those stuff at the end and therefor reduce some parts... (like restarting services, it often happens with a larger update to have the same service restarted multiple times)

but the major point is that, the updates would be done nicely and no 'hang points' points where it seems nothing happens between updates.

obviously this is low priority, but i don't see this as a reason to close it. if it's not urpmi, can you or anyone else help me out finding what i should assign it to?

Status: RESOLVED => REOPENED
Resolution: INVALID => (none)

Comment 4 Thierry Vignaud 2012-03-13 23:09:18 CET

filetriggers already happened at end of transactions and that's the best we can do since one can interrupt between transactions which would mean we would lost file triggers events.

Doing so as posttrans instead of post already reduce the number of invocations (that was the whole idea behind file triggers)
And we cannot do any progress bar at all since we cannot know at which point is gtk-icon-cache, fc-cache, ldconfig, dkms and the like

Status: REOPENED => RESOLVED
Resolution: (none) => INVALID
Assignee: thierry.vignaud => bugsquad
Source RPM: urpmi => (none)

Comment 5 AL13N 2012-03-13 23:20:39 CET

ic your point now, however, if we store filetriggers, maybe there's a way to do it

(In reply to comment #4)
> filetriggers already happened at end of transactions and that's the best we can
> do since one can interrupt between transactions which would mean we would lost
> file triggers events.

ic, this is why i wanted to find a way to "store" file triggers to happen, so that even when breaking transactions, they wouldn't be lost. (and a manual command to start the uncompleted or failed filetriggers)

> Doing so as posttrans instead of post already reduce the number of invocations
> (that was the whole idea behind file triggers)
> And we cannot do any progress bar at all since we cannot know at which point is
> gtk-icon-cache, fc-cache, ldconfig, dkms and the like

if we'd "store" them, we could have at the end eg: 5 filetriggers to happen, so we could have a rudimentary scale of 20% steps... or just even some kind of label to let even rpmdrake users know which filetrigger is now running.