Hi guys, On Tue, Mar 19, 2013 at 12:07:20AM +0100, Francesco Poli wrote: > On Sun, 17 Mar 2013 17:34:03 +0800 Daniel Hartwig wrote: > > [...] > > On 17 March 2013 16:17, Francesco Poli <invernom...@paranoici.org> wrote: [..] > ยท -n, --force-no Assumes that you select no for all questions. > This option is assumed if stdout is not a terminal or if > /dev/tty cannot be opened. > > Hence, I would say that, when there is no controlling terminal, > apt-listbugs falls back to a non-interactive behavior (assuming a > negative answer for each question that would otherwise be asked to the > user). > This implies that, if the upgrade or installation risks introducing RC > bugs into the system, then the (non-interactive) apt session is forced > to stop. Otherwise, everything goes on, as if apt-listbugs were never > invoked. [..] > > - abort always when RC bugs. > > > > The second is, IMO, the more reasonable default. > > I believe it's the currently implemented default. > > > Ideally, the minimum > > severity of bugs to cause abort should be configurable but that is yet > > another wishlist :-) > > Assuming I am not misinterpreting what you wrote, this is already > possible: by modifying /etc/apt/apt.conf.d/10apt-listbugs the user may > add options to the apt-listbugs invocation, among which the -s option > may be used to define which bug severities he/she is interested in.
It might be useful to forget about mechanics for a moment and think about the use cases that we'd like to support for "Debian testing" users of high level package managers (packagekit and the like). I think technical minded users would appreciate the same level of options currently provided by apt-get ran as root, ie. to be able to upgrade selected RC-buggy packages while pinning others. Less savvy users (eg. someone who can't tell the different between a DFSG-violation and system-wide breakage) would be served best by upgrading all upgrade-able packages except for those that are RC-buggy. In practise, this means pinning any RC-buggy packages (what the patch for #441689 does) and proceeding with the upgrade (after an apt-get re-invocation, or whatever action is required for the pinning to become effective). Do you agree about these use cases or do you have others to suggest as more important? Back to mechanics: The current non-interactive default (with --force-no) of aborting the whole upgrade in the face of any RC bug means that users are denied of (potentially security-critical) updates to packages that are safely upgrade-able. I consider this unacceptable if we're serious about supporting Debian testing. Severity based filtering (-s) seems meaningless to me. I'd never do blind upgrades based on a "ignore bugs up to X severity" policy, because that doesn't say anything about the packages and package features that I rely on as a user. -- Every great idea is worthless without someone to do the work. --Neil Williams -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
