Bug 1237132

Agree about PACAKGE.

update/updated - we actually get these strings directly from yum. Not sure if they are part of its api - of course we can easily "translate" them but this will break if yum changes them (unlikely, it's currently phased out in favor of dnf).

If it's currently used in yum I'm ok with it.

However see example:

---> Package sanlock.x86_64 0:2.8-1.el6 will be updated
---> Package sanlock.x86_64 0:2.8-2.el6_5 will be an update

Those few words ('will be' / 'will be an') can be much more informative than just 'update'/'updated'.

For records, BZ#1028157 is a KDE bug, not really related to this one.

Thank you for noticing, correct bug here: BZ#1168629

Moving to 3.6.1 since we passed String Freeze on 2015-08-19

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

New listing example:


Setup has found updates for some packages:
          .21-5.el7.noarch
          [install] jackson-core-2.6.3-1.el7.noarch
          [install] jctools-1.1-0.3.alpha.el7.noarch
          [install] libyaml-0.1.4-11.el7_0.x86_64
          [update] ovirt-engine-dbscripts-4.1.0.4-1.el7.centos.noarch [updated] ovirt-engine-dbscripts-4.0.7.4-1.el7.centos.noarch
          [update] ovirt-engine-dwh-4.1.0-1.el7.centos.noarch [updated] ovirt-engine-dwh-4.0.8-0.1.master.20170301104656.el7.centos.noarch
          [update] ovirt-engine-dwh-setup-4.1.0-1.el7.centos.noarch [updated] ovirt-engine-dwh-setup-4.0.8-0.1.master.20170301104656.el7.centos.noarch
          [update] ovirt-engine-extensions-api-impl-4.1.0.4-1.el7.centos.noarch [updated] ovirt-engine-extensions-api-impl-4.0.7.4-1.el7.centos.noarch
do you wish to update them now? (Yes, No) [Yes]:

Lukas, is the output in comment #7 good for you?

install lines seems, however packages which are updated still might be confusing

[update] ovirt-engine-dbscripts-4.1.0.4-1.el7.centos.noarch [updated] ovirt-engine-dbscripts-4.0.7.4-1.el7.centos.noarch

I would say this means update for package ovirt-***-4.1.0 and after it will be updated it will be ovirt-***-4.0.7

which is exact opposite, just the new version would make much more sense as I believe the confusing part is in the word [updated], as it is parsed from yum where the exact words are 'will be updated' 'will be an update' and the rest is cut out

I suggest:
a) without the old version
  [install] libyaml-0.1.4-11.el7_0.x86_64
  [update] ovirt-engine-dbscripts-4.1.0.4-1.el7.centos.noarch
b) with better naming
  [install] libyaml-0.1.4-11.el7_0.x86_64
  [update] ovirt-engine-dbscripts-4.1.0.4-1.el7.centos.noarch to package ovirt-engine-dbscripts-4.0.7.4-1.el7.centos.noarch

or something similiar to b), I am against having just words update and updated as without 'will be' and 'will be an' they have opposite meaning

I didn't check yum sources, but otopi gets from yum only 'update', 'updated' (among others). So I guess yum's cli _adds_ "will be". We can do that too, of course, with the (small?) risk that the "translations" will fail if/when we bump into an untranslated verb (in which case we can probably simply output it as-is, no big risk actually).

Second listing example:
Covering the 4 main operations: update, updated, obsoleted, obsoleting

[install] libtool-ltdl-2.4.2-21.el7_2.x86_64
[update] ovirt-engine-4.1.1.6-0.1.el7.noarch will be updated to ovirt-engine-4.1.0.4-0.1.el7.noarch
[obsoleted] ovirt-engine-hosts-ansible-inventory-4.1.0.4-0.1.el7.noarch will be removed
[obsoleting] ovirt-engine-metrics-1.0.1-1.el7ev.noarch will be installed

Lukas, is that look better?

looks great, understandable, readable

push it, merge it, ship it! 

just a small typo:
[update] ovirt-engine-4.1.1.6-0.1.el7.noarch will be updated to ovirt-engine-4.1.0.4-0.1.el7.noarch

I would really not recommend updating to lower version, thus I would say it should say will be updated from


thanks for the effort!

After some more tests, I figure that the lines were too long and not readable as it should be. It is hard to find the package name between the lines and in cases that have many updates it looks messy.

So we come back to a line for each package and it looks like this:

[updated] ovirt-engine-backend-4.1.0.4-0.1.el7.noarch will be updated
[update] ovirt-engine-backend-4.1.1.6-0.1.el7.noarch is an update
[install] libtool-ltdl-2.4.2-21.el7_2.x86_64 will be installed
[obsoleted] ovirt-engine-hosts-ansible-inventory-4.1.0.4-0.1.el7.noarch will be removed
[obsoleting] ovirt-engine-metrics-1.0.1-1.el7ev.noarch will be installed

This display is much more readable in my opinion.

Lukas, do you agree?

looks awesome

Verified in ovirt version 4.2.0-0.0.master.20170903205106.gitb17261a.el7.centos.

Output:
 ...
 [updated] ovirt-...-11.0.0-1... will be updated
 [update] ovirt-...-11.0.1-1... is an update
 ...

This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.