[pacman-dev] [PATCH 4/8] Update the event callback

[Olivier Brunel]

On 01/12/14 15:33, Andrew Gregory wrote:
> On 01/10/14 at 03:16pm, Olivier Brunel wrote:
>> On 01/10/14 14:25, Allan McRae wrote:
>>> On 10/01/14 23:14, Olivier Brunel wrote:
>>>>
>>>> - What's your opinion regarding what I mentioned before:
>>>> I don't think addressing FS#36504 was right. This was about moving the
>>>> log messages about a package being installed/upgraded/etc before the
>>>> scriptlet messages, and not after as they were. I think this might have
>>>> been a mistake:
>>>> I guess it all depends on when you consider the operation to be
>>>> completed, once pacman's extraction reached 100%, or after the scriptlet
>>>> have run. I feel the later is right, since they are part of the process
>>>> of installing/upgrading/etc a package; Of course, you may disagree.
>>>>
>>>> Either way, the current situation is wrong, because right now ALPM does:
>>>>   1. add log message about the operation being done
>>>>   2. run scriptlet
>>>>   3. signal frontend (via event) that operation is done
>>>>
>>>> IOW if a frontend was to actually use the event to present its output to
>>>> the user, it wouldn't match the order in the log, which is wrong. This
>>>> was done because pacman ignores that event, only showing the progress of
>>>> the extraction, and thus people feel that it goes 1. install done; then
>>>> 2. scriptlet.
>>>>
>>>> In fact, pacman doesn't really ignore the event, and uses it to show
>>>> (new) optdep. Should this be done before or after the scriptlet?
>>>> One could also ask, when using --noprogressbar pacman doesn't say
>>>> anything at the end of the operation (save for optdep), imagine it
>>>> would: should it be before or after the scriptlet?
>>>>
>>>> As I said, I think the logging should be moved after the scriptlet have
>>>> run, as this is when the operation is really done. If you were to
>>>> disagree though, then the event should be moved before the scriptlet
>>>> run, to keep consistency between the frontend and the log (which is
>>>> broken ATM), but this just feels wrong to me, since then a frontend
>>>> would consider a package upgrade/etc done, when in fact the scriptlet
>>>> have yet to run (and produce new output relating to the operation
>>>> supposedly done).
>>>
>>> I'd like Andrew to comment here as I think that was his patch.  I think
>>> arguments can be make both ways here.  Maybe signal the frontend it is
>>> done installingg at the same time as the log and add signals that
>>> install scriptlets are running?  I think this is independent of your
>>> patchset, or am I missing something?
>>
>> Yeah it is, I did keep things (in) the same (order) and the fix should
>> be a separate patch indeed, I just didn't want this to be forgotten is all.
> 
> If I understand your proposal, you're suggesting that we *break*
> pacman's consistency with the log in order to make it easier for other
> front-ends to be consistent with it.  That seems like a step in the
> wrong direction if you care about front-end/log consistency.

Ok, after looking into this more, it seems the issue might be one of
log/frontend "consistency," or more specifically what the log message
"package updated" means.

As in, I was linking it to the entire package operation, and therefore
it was (in my mind) linked to the corresponding event. The fact that the
logging of the message & the event occurred at different moment was then
thought of as a mistake.

You seem, OTOH, to link it to mean the db update was done, nothing else
-- it just so happens that pre-install scriptlet & file extraction, when
performed, takes place prior to db update, while post-install scriptlet
do not, but that's irrelevant.

I get the point about how "the log should reflect the current state of
the system" to want to place the log message at that moment, but I'm not
sure about it.
As in, I feel it would make more sense (from a user perspective?) if all
log messages relating to a package were found before the "package
installed" one, and not some before (e.g. pre-scriptlet, some warnings:
pacnew, etc) and some after (post-scriptlet). Seems clearer/more consistent.

Besides, it's not like all log messages allow to reflect the state of
the system, after all the "synchronizing package lists" doesn't mean
anything in that regard, really (you don't know which repos/dbs were
upgraded, if any).

And, again, as far as users go (not ALPM), a package is installed when
the entire package operation is done, not just the db update.


In a way it relates to the FS#36504, which was about moving the log
messages about a package being installed/upgraded/etc before the
scriptlet messages, and not after as they were.

The reasoning given was that pacman does it the other way around, which
is actually wrong (it appears that way when you view the 100% of the
file extraction process to mean operation completed, which it isn't
yet), if you consider the entire package operation.

(In fact, pacman might add extra output after the operation is done,
things about optdep. This happend after the operation is done, i.e. on
the event, so after the scriptlet have run, not before.)

It might look like there's no consistency between pacman & the log only
because pacman doesn't show any output at the end of the package
operation, so people assume the 100% of file extraction was it. It wasn't.

But if you insist that the log message should reflect the db update
operation, then I guess everything happens at the right moment.
I myself still feel this would be more of a debug message (which already
exist), and this regular log message really should refer to the (entire)
package operation (and therefore be moved after post-scriptlet).

-j

> The reason I moved the logging was really about log integrity.
> Resolving FS#36504 was just a happy coincidence.  The log and
> front-end output serve two different purposes, and their similarity is
> not very important (they aren't even in the same language for
> non-English users).  The log should reflect the current state of the
> system.  As far as alpm is concerned, the package is installed as soon
> as it's added to the local db, so that is the correct time to log it.
> 
> I would imagine that users and, by extension, front-ends are generally
> more likely to be interested in when the entire installation process,
> including scripts, is done.  I would be fine with adding new events as
> Allan suggested as long as the end of the entire installation process
> can still be reliably detected by the front-end.  Spawning a new
> process and running arbitrary code from the packager does seem like
> the sort of thing we should be notifying front-ends about anyway.
> 
> apg
>