On Sat, Mar 11, 2023 at 07:16:52PM +0100, Axel Beckert wrote: > > Without it, the user who uses aptitude only may never be aware of > > this change […] > > This is wrong. Without doubt this type of information will be part of > the release notes — which is usually the _primary_ source for these > type of changes. I'm actually surprised that apt added such a message.
The message is primarily for people who have missed the release notes or any other form of announcement – which in the end is their fault, using sid isn't a hall pass for not actively interacting with Debian. I added it specifically to avoid at least a bit the flood of bugreports against apt we had after the security archive changed layout last release because "apt is throwing errors". Okay, this change isn't throwing any errors, so we would probably be mostly fine… so that is less "announcing a change" and more a "needless support and bugreport prevention attempt". That is also why the message sounds a bit strange – I am reusing existing message templates as I really didn't want to bother translators with a message which in an ideal world nobody sees. If I get the memo before a release, I can add such messages even if it is strictly a layer violation out of pure self-interest… while writing this code I was actually retiring code which detected sources.list entries referring to Debian mirrors via ftp:// and pointing to a Debian News entry announcing the decommissioning of ftp access. Another example of a notice from apt is if you have a sources.list entry like "http://user:passw...@example.org/";. In that case we are advertising apt_auth.conf(5) usage. You can find me rambling about n-f-f transition some more e.g. in: https://lists.debian.org/debian-devel/2022/10/msg00217.html https://salsa.debian.org/apt-team/apt/-/merge_requests/282 https://bugs.debian.org/1030189#42 But the gist is what I said here already as well: It isn't really apts job to announce such changes, but as nothing else really does it and apt is the thing affected and used by users, I implemented it anyhow in the least annoying and cost-efficient way (for me) last minute as nobody else showed any interest in another possible solution. > Besides that, the apt developers decided to output this only as LOW > severity message on the "notice" level (prefix by "N:" and in normal > font face; AFAIK the lowest level). We have sorta a lot of messages at the Notice level nowadays as not everything we want to bring to the attention of a user is a Warning – and Notices are shown only on interactive usage, not in logs or anywhere where they could confuse scripts and such. So, some Notices even accompany Warnings/Errors to explain them further as changing the initial message is hard(er) as it would break other stuff relying on it… > Anyway, back to the original topic. So I edited > /usr/include/apt-pkg/error.h temporarily and replaced all but the > first occurence (which is the definition) of WARNING with NOTICE and > then compiled aptitude against it. aptitude update indeed > showed notices now. But to my surprise not all of them, just this one: > > N: Skipping acquire of configured file 'main/binary-i386/Packages' as > repository 'file:/var/cache/apt-build/repository apt-build InRelease' doesn't > support architecture 'i386' > > Not yet sure if this is a bug in the way how the missing notices are > generated in apt or if it is a bug in aptitude not coping with the > changed default message threshold. Likely needs deeper investigation It is actually (in a way) a small bug in your personal configuration. :) libapt is trying to tell you that you have a Multi-Arch system (I guess amd64 and i386 configured), but this repository does not support the i386 architecture – which might be completely harmless or it could be a problem later on if you try to install stuff from it, depending on what you install from it (imagine trying to install a newer version of a library you have installed from both arches, but now only amd64 is available…). You can silence this notice either by telling apt which architectures you wanna get from that repository (depending on how you like things, something like [arch=amd64] or [arch-=i386] would work I guess) OR [preferably] the repository declares support for i386: That would automatically happen if you would build & ship packages for that architecture, but you can also just provide an empty Packages file or no Packages file at all and just add i386 to the Architectures field in the Release file. That tells apt that the repository owner cares for users with that architecture, so presumably a user wont run into issues – or at least will have a better experience than "closed, unsupported, go away" to bug reports if something goes wrong. While this is technically predicting a possible problem in the future, it is so unspecific that annoying users with a warning wouldn't be right. > I'm also surprised that, despite the default threshold in > /usr/include/apt-pkg/error.h is WARNING, both, "apt update" and > "apt-get update" show notices. So the apt developers changed the > thresholds for both CLI frontends individually? Weird. Well, imagine we would have changed them for ALL libapt users… given that you speak about popups and annoyance levels in your own mail… What should unattended-upgrades do with those notices? What should a software-center-like thing do with them? So until we have better control over messages, so that a frontend can actually more programmatically decide which to show, which to hide and how to display them, I decided a while ago to bundle them into a new level and hide it away by default. Similar to how some front ends decide to not even bother with warnings (and some not even with errors, but that is a different story). > least those parts which were clear enough) and agree with the apt > developers that the message about the Debian bookworm change > concerning non-free-firmware is only a notice, not a warning. On a not unimportant side note: This notice (as well as my explicit examples ftp & auth.conf earlier) is apt{,-get} specific, so even if aptitude would show notices, it wouldn't show this one as the code generating them is not in libapt, mostly because it can not really be there. The update-code shared in libapt is only concerned with updating the files, but which sources.list files are (not) involved and if and how the caches are (re)build is an individual application decision. The notice generation needs to know this through, so we would need a new API for that… and if that new API is just generation messages, shouldn't it be better at generating them. I mean, giving you a couple lengthy strings to display as-is to the user? Shouldn't the URI be clickable? And why isn't the package name? Oh, and the filename of the sources.list file? Heh, how about opening it… (see the last paragraph) WAY to much design work for something I initially didn't even want to implement in apt to begin with. I hope that clear this sorta misunderstanding up at least a bit. Best regards David Kalnischkies
signature.asc
Description: PGP signature
_______________________________________________ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
