Description of problem: When updating engine via engine-setup update for packages listing which were introduced by BZ#1028157 feels out of context and uninformative. example: Setup has found updates for some packages: PACKAGE: [updated] ovirt-engine-3.6.1-0.0.el6.noarch PACKAGE: [update] ovirt-engine-3.6.0-0.0.el6.noarch PACKAGE: [updated] ovirt-engine-backend-3.6.1-0.0.el6.noarch PACKAGE: [update] ovirt-engine-backend-3.6.0-0.0..el6.noarch do you wish to update them now? (Yes, No) [Yes]: Version-Release number of selected component (if applicable): ovirt-engine-setup-3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch How reproducible: 100% Steps to Reproduce: 1. updated ovirt-engine-setup to newer version 2. wait for packages that will be updated to be listed Actual results: PACKAGES - no need to be all capital letters, this way it feels out of context with other part of ovirt-engine log. [updated] & [update] terms are confusing and not informative Expected results: similiar format to: Package: [current] ovirt-engine-3.6.0-0.0.el6.noarch Package: [updated] ovirt-engine-3.6.1-0.0.el6.noarch Additional info: PACKAGE->Package update -> current (or to be updated) switched order of these because I would expect future package version to be listed after past/current one
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.