Guillem Jover dixit: >Hmm, I've always considered that a bug, so I'd like to know how you >are using dpkg that makes you consider the old behavior a feature. :) > >I guess you use dpkg + dselect? Because AFAIC all other frontends >reset holds on installation.
I use dselect mostly for manual-interactive package removal. My actual use case for this bug-or-feature is this: I’m carrying local versions for console-setup and other packages which I then set on hold (since APT pinning is more effort and hold “just works”). When they get an update in sid, I rebase the patch and recompile, then I run an apt-get --purge dist-upgrade --ignore-hold which will upgrade those three but neither set them to manually installed nor reset the hold, normally. I don’t have a use case where anything really breaks, just minor inconveniences (like this one) or (in one other case) having to force a downgrade afterwards, which may not be nice (where rebasing the local patch on top of something newer, while definitely on the TODO, hasn’t happened yet), but that’s $dayjob stuff. Have a nice evening, //mirabilos -- 18:47⎜<mirabilos:#!/bin/mksh> well channels… you see, I see everything in the same window anyway 18:48⎜<xpt:#!/bin/mksh> i know, you have some kind of telnet with automatic pong 18:48⎜<mirabilos:#!/bin/mksh> haha, yes :D 18:49⎜<mirabilos:#!/bin/mksh> though that's more tinyirc – sirc is more comfy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
