DNF package upgrade availability/discovery blocked by versionlocks

[Felix Miata]

[mc-4.8.18 has been broken since release, so I locked 4.8.17]

# grep RETT /etc/os-release
PRETTY_NAME="Fedora 26 (Twenty Six)"
# dnf versionlock list
Last metadata expiration check: 1:33:30 ago on Thu Mar 23 16:44:17 2017 EDT.
mc-1:4.8.17-2.fc25.*
# dnf list mc
Last metadata expiration check: 1:33:33 ago on Thu Mar 23 16:44:17 2017 EDT.
Installed Packages
mc.x86_64	1:4.8.17-2.fc25	@System
# dnf check-update mc
Last metadata expiration check: 1:33:35 ago on Thu Mar 23 16:44:17 2017 EDT.
#
# dnf versionlock delete mc
Last metadata expiration check: 1:41:52 ago on Thu Mar 23 16:44:17 2017 EDT.
Deleting versionlock for: mc-1:4.8.17-2.fc25.*
# dnf list mc
Last metadata expiration check: 1:41:58 ago on Thu Mar 23 16:44:17 2017 EDT.
Installed Packages
mc.x86_64	1:4.8.17-2.fc25	@System
Available Packages
mc.x86_64	1:4.8.18-4.fc26	fedora
# dnf check-update mc
Last metadata expiration check: 1:42:08 ago on Thu Mar 23 16:44:17 2017 EDT.
mc.x86_64	1:4.8.18-4.fc26	fedora
#

How is one expected to discover via dnf when (18 day old) 4.8.19 finally becomes 
available and time to delete the lock has arrived? Is this a bug in the 
versionlock plugin? DNF itself? Expected behavior?
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[Michael Mraka]

Felix Miata:
>  [mc-4.8.18 has been broken since release, so I locked 4.8.17]
>  
>  # grep RETT /etc/os-release
>  PRETTY_NAME="Fedora 26 (Twenty Six)"
>  # dnf versionlock list
>  Last metadata expiration check: 1:33:30 ago on Thu Mar 23 16:44:17 2017 EDT.
>  mc-1:4.8.17-2.fc25.*
>  # dnf list mc
>  Last metadata expiration check: 1:33:33 ago on Thu Mar 23 16:44:17 2017 EDT.
>  Installed Packages
>  mc.x86_64	1:4.8.17-2.fc25	@System
>  # dnf check-update mc
>  Last metadata expiration check: 1:33:35 ago on Thu Mar 23 16:44:17 2017 EDT.
>  #
>  # dnf versionlock delete mc
>  Last metadata expiration check: 1:41:52 ago on Thu Mar 23 16:44:17 2017 EDT.
>  Deleting versionlock for: mc-1:4.8.17-2.fc25.*
>  # dnf list mc
>  Last metadata expiration check: 1:41:58 ago on Thu Mar 23 16:44:17 2017 EDT.
>  Installed Packages
>  mc.x86_64	1:4.8.17-2.fc25	@System
>  Available Packages
>  mc.x86_64	1:4.8.18-4.fc26	fedora
>  # dnf check-update mc
>  Last metadata expiration check: 1:42:08 ago on Thu Mar 23 16:44:17 2017 EDT.
>  mc.x86_64	1:4.8.18-4.fc26	fedora
>  #
>  
>  How is one expected to discover via dnf when (18 day old) 4.8.19
>  finally becomes available and time to delete the lock has arrived?
>  Is this a bug in the versionlock plugin? DNF itself? Expected
>  behavior? 
If you locked 4.8.17 then dnf ignores all other versions.
That's how versionlock is supposed to work, i.e. expected behavior.
If you want to ignore broken version it's better to put just this one to exclude.

--
Michael Mráka
System Management Engineering, Red Hat

[Felix Miata]

Michael Mraka composed on 2017-03-24 08:54 (UTC+0100):

>  Felix Miata: 
> > [mc-4.8.18 has been broken since release, so I locked 4.8.17]
...
> > How is one expected to discover via dnf when (18 day old) 4.8.19
> > finally becomes available and time to delete the lock has arrived?
> > Is this a bug in the versionlock plugin? DNF itself? Expected
> > behavior? 
>  If you locked 4.8.17 then dnf ignores all other versions.
>  That's how versionlock is supposed to work, i.e. expected behavior.
>  If you want to ignore broken version it's better to put just this one to exclude.
The "supposed to work" way you describe seems would make all packages except the

broken one invisible. Seems like only a broken design could make a usable 
replacement invisible in searches. Locking should only make filesystem action 
regarding a package locked, not pretend other versions are invisible. IOW, 
ignoring should be about action (install/upgrade/remove), not about existence 
(mere inquiry, not prevent discovery), like a Debian hold works.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[Honza Silhan]

On Fri, Mar 24, 2017 at 10:38 AM, Felix Miata <mrmazda(a)earthlink.net&gt; wrote:
>  Michael Mraka composed on 2017-03-24 08:54 (UTC+0100):
>
> > Felix Miata:
>
>
> >> [mc-4.8.18 has been broken since release, so I locked 4.8.17]
>
>  ...
> >>
> >> How is one expected to discover via dnf when (18 day old) 4.8.19
> >> finally becomes available and time to delete the lock has arrived?
> >> Is this a bug in the versionlock plugin? DNF itself? Expected
> >> behavior?
>
>
> > If you locked 4.8.17 then dnf ignores all other versions.
> > That's how versionlock is supposed to work, i.e. expected behavior.
> > If you want to ignore broken version it's better to put just this one to
> > exclude.
>
>
>  The "supposed to work" way you describe seems would make all packages except
>  the broken one invisible. Seems like only a broken design could make a
>  usable replacement invisible in searches. Locking should only make
>  filesystem action regarding a package locked, not pretend other versions are
>  invisible. IOW, ignoring should be about action (install/upgrade/remove),
>  not about existence (mere inquiry, not prevent discovery), like a Debian
>  hold works. 
Hi, for non-transactional operations (search, list, info) packages
could be made visible. I am not sure how yum versionlock behave in
this situation. This PR [1] should introduce this behavior.


Honza

[1] https://github.com/rpm-software-management/dnf-plugins-extras/pull/90