NetBSD Problem Report #51417

From  Wed Aug 17 07:36:06 2016
Return-Path: <>
Received: from ( [])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "", Issuer "Postmaster" (verified OK))
	by (Postfix) with ESMTPS id 0A7D37A266
	for <>; Wed, 17 Aug 2016 07:36:06 +0000 (UTC)
Message-Id: <>
Date: Wed, 17 Aug 2016 09:35:59 +0200 (CEST)
Subject: pkgin should put all interaction up-front
X-Send-Pr-Version: 3.95

>Number:         51417
>Category:       pkg
>Synopsis:       pkgin should put all interaction up-front
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    jperkin
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 17 07:40:00 +0000 2016
>Closed-Date:    Mon Apr 20 10:37:54 +0000 2020
>Last-Modified:  Mon Apr 20 10:37:54 +0000 2020
>Release:        NetBSD 7.0
System: NetBSD 7.0 NetBSD 7.0 (GENERIC.201509250726Z) amd64
Architecture: x86_64
Machine: amd64
	pkgin can in at least two cases ask interactive questions at
	... "inconvenient times":

	1) During "pkgin fug" it may have done lots of downloads
	   before it discovers that the package repository doesn't
	   have either the "xv" program nor the "adobe-flash-plugin"
	   package (e.g. when one of the dependencies is going to be

	   pkgin will then abort the download, and at that point
	   forcing the operator to manually remove the package
	   (possibly after pkg_tarup) before re-doing "pkgin fug".

	   Instead, pkgin should discover this up-front before
	   starting the download phase, and possibly refuse to proceed
	   before the problem is fixed as suggested above.

	   This so that the operator can do away with all the
	   interaction up front and then proceed to let pkgin complete
	   the task on its own without the need for further

	2) During a "pkgin fug", when upgrading to a new pkgsrc
	   branch, it's likely that the pkg_install package will need
	   to be upgraded.  However, pkgin insists on an
	   interactively-given permission for upgrading this package,
	   and insists on that interaction before upgrading this
	   particular package, which, it appears, is always the first
	   package to be upgraded (if it will be upgraded).

	   This happens after a long phase of non-interaction
	   (download of new packages and removal of all packages which
	   will be upgraded).  Somehow pkgin appears to consider
	   pkg_install a "special" packge that it needs special
	   permission to upgrade (why?!?).

	   Meanwhile the system keeps sitting there with possibly
	   precious few packages installed, probably in a state of
	   strictly reduced functionality compared to what the
	   operator intended.

	   I would primarily suggest that the interactive promt for
	   upgrading pkg_install be abolished altogether (what happens
	   if you say "no"?  Does it abort the whole upgrade?).
	   Alternatively if the prompt is retained, I would suggest
	   that the question be asked *before* the download of the new
	   packages is started, so that it happens at a time when the
	   operator has attention.

	Ref. description above.

	Suggested fixes of behaviour given above.  No code, though...



Responsible-Changed-From-To: pkg-manager->imil
Responsible-Changed-When: Wed, 17 Aug 2016 07:56:42 +0000
Emile, can you please give a look? (over to MAINTAINER)

Responsible-Changed-From-To: imil->pkg-manager
Responsible-Changed-When: Mon, 02 Apr 2018 09:34:34 +0000
imil observes

Responsible-Changed-From-To: pkg-manager->jperkin
Responsible-Changed-When: Tue, 03 Apr 2018 14:32:07 +0000
I'll take this.

State-Changed-From-To: open->closed
State-Changed-When: Mon, 20 Apr 2020 10:37:54 +0000
This has been resolved over the last few years with a number of changes
made to how interaction is handled.


NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD:,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.