Hi, On Thu, Jun 25, 2015 at 05:07:58PM +0200, Guillem Jover wrote: > Skimming over the git log for the debian/experimental branch, I > noticed commit 374f8492e6f109e8427816a8f513e5e8feda9049, which does > not make much sense to me. > > Uninstalled packages cannot be put on hold, dpkg will just ignore such > state, and mark it as «unknown ok not-installed» anyway. Was there any > other reason for that change? This used to work in the past (no idea how long that past is ago through) and the change was done based on complains that you can't do it with apt while you could via selections (I remember trying/using this in the past, interestingly I failed to encode it in the test, mmhhh…). The point is that $packagemanagers hold the package in the state it is currently in if a package is on hold, which in that case is uninstalled. So, a trivial way of tricking a packagemanager to not choose the "wrong" solution e.g. for alternatives. There are other ways, but nothing as generic/universal I would guess. $packagemanagers is here at least most of libapt users (the only exception might be aptitude which has its problem with respecting dpkg holds at times). If that is gone for good… I am not sure yet how to reintroduce a permanent "do not install" for apt then. -1 pinning is kinda similar, but not quiet. > (BTW, in case interfaces are not apt, I'd like to think a bug report or > a discussion in debian-dpkg might probably be more fruitful than snide > remarks on a commit message. :) It wasn't meant as snarky as it might sound now. I can understand that dpkg wants to know about packages, that isn't a bug, it is just something we have to deal with and given there isn't a good reason to push all Packages files data into the available file of dpkg beside this very minor apt-mark feature so far, I was deploying this "ugly" trick. If we have a reason to push all data in that direction that is fine and based on the dpkg todolist its on the agenda for discussion, but until then it would be just multiple MBs of duplicated and unused data, so "[…] what would be the point really [at this point in time]? Exactly […]". The rest is poking fun at myself as I was clearly tricked once again by the chorus of "come on, that can't be too hard to implement: You just have to wrap a single call!". Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature