[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")



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


Andreas

PS: my apt pinning is exactly setup to prevent unwanted release
changes even if sources.list contains everything from wheezy to
experimental ;-)


Reply to: