On Mon, Jul 08, 2019 at 11:19:28AM +0200, Andreas Beckmann wrote: > Followup-For: Bug #931566 > Control: tag -1 experimental > > IMHO, the intention behind this change is good. > The implementation was completely untested. Well, it's kind of hard to > properly test such a change. > The documentation is not really helpful. > > I initially thought this was caused by my rather complicated setup. > Until I experienced it on a machine installed with buster two weeks ago > and not yet "customized" by me. > > Multiple errors like this: > E: Repository 'http://security-cdn.debian.org stretch/updates InRelease' > changed its 'Suite' value from 'stable' to 'oldstable' > N: This must be accepted explicitly before updates for this repository > can be applied. See apt-secure(8) manpage for details. > > apt-secure(8) says: > > INFORMATION CHANGES > A Release file contains beside the checksums for the files in the > repository also general information about the repository like the > origin, codename or version number of the release. > > This information is shown in various places so a repository owner > should always ensure correctness. Further more user configuration > like apt_preferences(5) can depend and make use of this > information. > Since version 1.5 the user must therefore explicitly confirm > changes to signal that the user is sufficiently prepared e.g. for > the new major release of the distribution shipped in the > repository (as e.g. indicated by the codename). > > OK, and what do I do now? How do I confirm that? > > It took me some time to discover --allow-releaseinfo-change in > apt-get(8).
Please let's not discuss the manpage here. Bug#879786 has been filed for that back in Oct 2017. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
