After release of Debian 10 there were two problems with updates on my servers:

sources.list configured for buster refused to update, because of suite change
sources.list configured for stable performed update without a hint to the suite change

for the first one I had to reconfigure to stable, run an update, reconfigure to buster and run the update again
the latter one is a misconfiguration of mine, but should result in a warning

Am 07.07.2019 um 14:05 schrieb Michael Becker:

This has been noted before, e.g. in bug #931536.  Note that the message
actually comes from libapt and is new in buster, i.e. stretch's apt
would not issue it.

You could also run "apt update", it interactively asks for confirmation.
Aptitude currently does not, probably because none of the apt developers
mentioned that this would now be necessary.

If you were running "stable" until yesterday, you still had aptitude
and apt from stretch which do not show this warning.  But apt from
buster will refuse to update by default, just as in the first case you
mentioned.

Cheers,
       Sven

Hi Francesco, Michael and Sven,

Francesco Poli (wintermute) wrote:
[…]

Indeed. This also seems to have an impact where buster changed from
"testing" to "stable", see https://bugs.debian.org/931543.

That's actually prompted by a change in libapt (as Sven already
pointed out in #931543) which aptitude indeed hasn't been updated a
for.

I though must admit that we actually were aware of this issue as I ran
into it with a third-party repo a few months ago, see
https://bugs.debian.org/915246. But admittedly I totally
underestimated its severity and especially also its impact at release
time as I didn't think of that exactly the same will happen when
Debian shifts all suite names at release time. Sorry for that.

I hope that Manuel (CCc'ed) can provide a fix which we then can also
apply to aptitude in Buster in the first minor update which is
expected in about a month.

The official workaround is to use "apt update" once inbetween, answer
its questions (with "y" :-) and then continue to use aptitude.

		Regards, Axel

Hello Axel, thanks for chiming in!

[...]
[...]
[...]

It's OK, luckily we have the simple "apt update" workaround (although
many people will have to be informed about it...).

I am looking forward to seeing this fix implemented.

Bye!

into extending the reporting let me add some implementation hints:
(Note that this is against apt/master which has some API changes, but in
that case that means ABI-compat classes where folded into another, so
backports should be rather trivial – adding virtual methods is ABI
breaking, so in buster the class to derive from has the creative name
pkgAcquireStatus2 as it is itself derived from pkgAcquireStatus)

libapt has a pkgAcquireStatus class which gained a new virtual method:
ReleaseInfoChanges – kinda similar to the existing MediaChange. aptitude
subclasses this a few times, just pick the right one I guess.

See apt{,-get}s implementation:
https://salsa.debian.org/apt-team/apt/blob/master/apt-private/acqprogress.cc#L334

I guess you want to work directly with the parameter
std::vector<ReleaseInfoChange> &&Changes rather than do the trickery to
make "proper" apt error messages out of it and then print them directly
by wrap-calling the default implementation I did there – aka it is
probably simpler for you.

See the doc for the struct in the method in the header:
https://salsa.debian.org/apt-team/apt/blob/master/apt-pkg/acquire.h#L797

And the code generating the messages you can reuse via the struct:
https://salsa.debian.org/apt-team/apt/blob/master/apt-pkg/acquire-item.cc#L1806

If I could make a wish I would suggest featuring the messages which
don't need confirmation (in apt N: lines) not too prominently – as in
don't make them a popup dialog with an OK button (while the other type
is a popup dialog with yes and no buttons). 😉


I can't speak for aptitude folks and I am not too good with aptitude
code, but if I would be that might be a good bug for tagging +newcomer.
Happy to help in case there are {lib,}apt questions in any case – although
I have insane reply delays currently.


Best regards

David "breaking the world one feature at a time" Kalnischkies

On Sun, 7 Jul 2019 16:41:27 +0200 Francesco Poli wrote:

[...]

Hello again!

After more than two years, this bug is still unfixed in aptitude...

  # cat /etc/apt/sources.list
  deb http://deb.debian.org/debian testing main
  deb http://deb.debian.org/debian unstable main

  deb http://deb.debian.org/debian-security testing-security main
  # aptitude update && aptitude --purge-unused safe-upgrade
  Get: 1 http://deb.debian.org/debian testing InRelease [81.6 kB]
  Get: 2 http://deb.debian.org/debian unstable InRelease [165 kB]
  Get: 3 http://deb.debian.org/debian-security testing-security InRelease [35.6 kB]
  Fetched 282 kB in 8s (36.6 kB/s)
  E: Repository 'http://deb.debian.org/debian testing InRelease' changed its 'Codename' value from 'bullseye' to 'bookworm'
  E: Repository 'http://deb.debian.org/debian-security testing-security InRelease' changed its 'Codename' value from 'bullseye-security' to 'bookworm-security'
  E: Failed to download some files
  W: Failed to fetch http://deb.debian.org/debian/dists/testing/InRelease:
  W: Failed to fetch http://deb.debian.org/debian-security/dists/testing-security/InRelease:
  E: Some index files failed to download. They have been ignored, or old ones used instead.


Once again, I had to work around the bug by using 'apt update':

  # apt update
  Get:1 http://deb.debian.org/debian testing InRelease [81.6 kB]
  Hit:2 http://deb.debian.org/debian unstable InRelease
  Get:3 http://deb.debian.org/debian-security testing-security InRelease [35.6 kB]
  E: Repository 'http://deb.debian.org/debian testing InRelease' changed its 'Codename' value from 'bullseye' to 'bookworm'
  N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
  Do you want to accept these changes and continue updating from this repository? [y/N] y
  E: Repository 'http://deb.debian.org/debian-security testing-security InRelease' changed its 'Codename' value from 'bullseye-security' to 'bookworm-security'
  N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
  Do you want to accept these changes and continue updating from this repository? [y/N] y
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  4 packages can be upgraded. Run 'apt list --upgradable' to see them.


At that point, I was able to resume my usual upgrade routine
with:

  # aptitude update && aptitude --purge-unused safe-upgrade



Are there any plans to fix this bug in aptitude once and for all?
Please

Hi,

Francesco Poli wrote:

Correct.

I assume so, yes. But not by myself as this is outside of my C/C++
capabilities. (In other words: I hope that Manuel — or someone else —
will find time to tackle this at some point with one of the next
upstream releases.)

Oh, and of course: Patches are welcome!

If there are well working patches, I can also apply them in the
upstream branches and do upstream releases with them. I just can't
write new C++ code from scratch. (I other words: Within the Aptitude
team, I'm primarily the package maintainer and Manuel does nearly all
of the upstream development.)

		Regards, Axel