On Fri, Mar 24, 2017 at 10:38 AM, Felix Miata <mrmazda(a)earthlink.net> 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