Re: Setting uninstalled packages on hold with apt-mark
Hey!
On Thu, 2015-06-25 at 23:30:51 +0200, David Kalnischkies wrote:
> 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…).
In principle the change in dpkg was done in commit
224f0285abc304bec059e6144778177c2eed06ee, when obsoleting
--forget-old-unavail, in dpkg 1.15.4 (2009-07). That's why this change
in apt, given the timing, seemed odd.
Although, now that I'm checking the claims in the dpkg commit message,
from bug #33394, I think that «hold ok not-installed» has never been
a state to denote a never-installed package in ancient times, it might
have been a system accidentally mass marked as such, but I'd have to
dig deeper to be sure.
In which case it might make sense to allow those back. Although of
course this does not fix the implementation annoyance of having to let
dpkg know about those packages first.
> 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).
Well, this has not been possible for a some time now. :) It's also
something that dselect never honored either. It does make sense though.
But an improved/rationalized handling of holds is probably worth of
being part of a general Package Manager Frontends Integration (or
similar) BoF at DebConf if apt, aptitude, and cupt maintainers are
going to be there? I could register such an event if there's interest.
> > (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
> […]".
Ah, understood. :)
Thanks,
Guillem
Reply to: