NetBSD Problem Report #51417

From he@smistad.uninett.no  Wed Aug 17 07:36:06 2016
Return-Path: <he@smistad.uninett.no>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 0A7D37A266
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 17 Aug 2016 07:36:06 +0000 (UTC)
Message-Id: <20160817073559.C179543E99C@smistad.uninett.no>
Date: Wed, 17 Aug 2016 09:35:59 +0200 (CEST)
From: he@NetBSD.org
Reply-To: he@NetBSD.org
To: gnats-bugs@NetBSD.org
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:    imil
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 17 07:40:00 +0000 2016
>Last-Modified:  Wed Aug 17 07:56:42 +0000 2016
>Originator:     he@NetBSD.org
>Release:        NetBSD 7.0
>Organization:
>Environment:
System: NetBSD smistad.uninett.no 7.0 NetBSD 7.0 (GENERIC.201509250726Z) amd64
Architecture: x86_64
Machine: amd64
>Description:
	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
	   upgraded).

	   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
	   interaction.

	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.

>How-To-Repeat:
	Ref. description above.

>Fix:
	Suggested fixes of behaviour given above.  No code, though...

>Release-Note:

>Audit-Trail:

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


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.