NetBSD Problem Report #55711

From martin@aprisoft.de  Sat Oct 10 13:44:14 2020
Return-Path: <martin@aprisoft.de>
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 "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 02AA31A923A
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 10 Oct 2020 13:44:13 +0000 (UTC)
Message-Id: <20201010134358.8F5725CC7A1@emmas.aprisoft.de>
Date: Sat, 10 Oct 2020 15:43:58 +0200 (CEST)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: sysinst could help auto-update scripts a lot
X-Send-Pr-Version: 3.95

>Number:         55711
>Category:       bin
>Synopsis:       sysinst could help auto-update scripts a lot
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sat Oct 10 13:45:00 +0000 2020
>Originator:     Martin Husemann
>Release:        NetBSD 9.99.73
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD whoever-brings-the-night.aprisoft.de 9.99.73 NetBSD 9.99.73 (WHOEVER) #349: Fri Sep 25 08:57:10 CEST 2020 martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/sparc64/compile/WHOEVER sparc64
Architecture: sparc64
Machine: sparc64
>Description:

sysinst(8) gets a lot of URL/path and release procedure information "burned
in", and we already need to make sure to keep this information up to date.

Duplicating the same information/knowledge elsewhere would be a bad idea.

A typical consumer of that information would be a script to auto update
binaries from daily builds and check for new releases.

Sysinst also could gain an "autopilot" option, that would silently go
through the "Upgrade NetBSD on a hard disk" path, select "current system"
and (selected by command line option) either go into interactive mode if
something goes wrong or just fail with an error message and abort.

For the information query it could offer to check for updates and download
the proper SHA512 file plus output the base url where it found this.
The update script then could (say) extract the SHA512 value for the etc
set, and if that did not change (which means /etc/release did not change),
nothing needs updating.

Another option could cause it to try to find a CHANGES file for the next
major release (i.e.: if we are on 9.2_STABLE, find an official 10.0 relesae),
and again output the url where to get it plus store the SHA512 file (from
which the script would extract the file names, w/o hard coding the file
suffix).

>How-To-Repeat:
n/a

>Fix:
n/a

Home	PR Database Search