|File: [cvs.NetBSD.org] / pkgsrc / sysutils / sysupgrade / Attic / TODO (download)
Revision 1.2, Wed Aug 15 21:21:15 2012 UTC (2 years, 8 months ago) by jmmv
CVS Tags: pkgsrc-2013Q2-base, pkgsrc-2013Q2, pkgsrc-2013Q1-base, pkgsrc-2013Q1, pkgsrc-2012Q4-base, pkgsrc-2012Q4, pkgsrc-2012Q3-base, pkgsrc-2012Q3
Changes since 1.1: +14 -0
Update to 1.1:
- Use shtk for the common utilities and configuration file parsing
functionality. The local copies of the "config" and "utils" modules
Things that sysupgrade could do
- Deduce the current NetBSD release from /etc/release and the target
release from etc.tgz and inform the user about the changes. This will be
necessary if the upgrade process needs to apply specific tweaks depending
on the affected NetBSD releases (which is not the case at the moment).
- Ability to automatically deduce the next upgrade target from a collection
of directories (e.g. from FTP). We should be able to tell sysupgrade to
follow along 6.0.x, or 6.x, or the daily builds and get it to pick the
most recent available build. Having to manually scan FTP directories to
select the correct build is... inconvenient.
- Ensure that the fetched sets belong to the current architecture. I have
bitten once by mistakenly pointing my custom update scripts to the wrong
platform directory, rendering the machine unusable as soon as base.tgz
- Download release checksums and validate files against them. The 'fetch'
command should unconditionally download the checksums every time it is
run and then deduce whether it needs to redownload (possibly-newer) sets
or do nothing.
- Add destdir support to etcupdate(8) and allow the 'etcupdate' command to
run when destdir is enabled.
- Maybe sysupgrade should be more interactive by default, letting the user
know what exactly is going to happen before doing so (e.g. what will be
the new version, where things are being downloaded from, etc.), and
providing a "quiet mode" flag instead. etcupdate is interactive anyway,
so adding more interactive steps (as long as they can be disabled) does
not seem a big deal.
Things that sysupgrade will NOT do
- Non-trivial rollbacks. If rollbacks are ever implemented, they should
be in the form of file system snapshots OR in the form of syspkgs.
Getting sysupgrade to magically store files aside to allow a later
rollback is just too fragile and hard to get right: rollbacks will
rarely will be necessary, but when they are it's very likely that a
tool like this is broken.