Re: [pacman-dev] [PATCH 2/2] Move logging of sysupgrade start, add log when done

On 12/16/12 16:02, Allan McRae wrote:

On 17/12/12 00:52, jjacky wrote:

...

On 12/16/12 15:38, Allan McRae wrote:

...

On 17/12/12 00:25, jjacky wrote:

...

On 12/16/12 15:05, Allan McRae wrote:

...

On 13/12/12 23:19, Olivier Brunel wrote:

...

The "starting sysupgrade" message was logged quite soon, making it be added even when nothing was actually done, because there was nothing to do, the user didn't confirm, or asked to only download packages.

The log message is now added only when (before) committing the transaction. And we also log a message at the end (in case of success or failure).

Signed-off-by: Olivier Brunel --- src/pacman/sync.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/pacman/sync.c b/src/pacman/sync.c index f8fce7f..77fd573 100644 --- a/src/pacman/sync.c +++ b/src/pacman/sync.c @@ -793,7 +793,6 @@ static int sync_trans(alpm_list_t *targets)

if(config->op_s_upgrade) { printf(_(":: Starting full system upgrade...\n")); - alpm_logaction(config->handle, "starting full system upgrade\n");

I really do not like that moving this prints effectively the same message at two different times. Also, the line below really is the start of the system upgrade.

By two different times, you mean to the user and in the log? In such a case, this first message could be something else, e.g. "preparing full system upgrade" or something to that effect, and moving the "starting" along with the log one.

What I don't like with the current situation, is that the message (in the log) says "starting sysupgrade" while it might not really be the case, because of a conflict, user didn't confirmed, or there was nothing to do. That's why I wanted the message to do logged before the operation was confirmed, and the sysupgrade will effectively be attempted/started.

This is where I completely disagree. I see the upgrade operation starting when pacman checks what is currently installed and whether there is a new version of it.

If there is a conflict in the packages, what failed? The system upgrade... so the system upgrade must have started...

Right. Well, it could be said/seen differently: as far as pacman goes, there's really two steps: - preparing the transaction - committing the transaction

You say the sysupgrade starts with step 1, which makes sense of course, but it could be argued that even after step 1 is completed, it hasn't really started. That's why then, between those two steps, pacman will ask the user whether to proceed or not. Or just stops if there's nothing to actually do.

Or, in other words, the system upgrade might start with step one, but the installation(*) does with step 2. Would you agreed with that?

(*) Noting it could actually be a download-only operation.

If so, I feel what should be logged is when the installation starts (and when it's completed/failed) and not when the upgrade (i.e. including the preparation/step 1) does.

This is mostly because I don't see the point of logging "starting sysupgrade" and then nothing, since we don't know why there's nothing. And e.g. logging "starting / nothing to do" seems useless to me.

Maybe the "starting sysupgrade" message could stay as/where it is, but not be logged, and the log message would be before the alpm_trans_commit call, but say "starting installation" instead ? (It could also be shown to the user as well, if that makes things clearer?)

Let take a step back...

The question that needs to be answered is "What is the benefit of moving that message?"

It would be moved right before updating packages. But ever package update is logged, so what is the gain?

Well, as I said, I'd like to avoid a log with "starting sysupgrade" and then nothing, not knowing why nothing happened (user not confirming, nothing to be done, file system conflict, etc). Moving it means in case of user not confirming or nothing to be done, nothing gets logged. Adding a completed/failed afterwards also makes things clearer, ensuring everything went fine (well, or not/failed but we know).

Allan