On Fri, Mar 24, 2017 at 10:38 AM, Felix Miata <mrmazda@xxxxxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
