On Fri, Oct 14, 2022 at 01:32:41PM +0800, Paul Wise wrote: > On Thu, 2022-10-13 at 17:35 +0200, Julien Cristau wrote: > > I'd prefer if we could make things work vs making things fail, > > however loudly. > > There seem to be a few ways to deal with this transition: (quotes reordered in Pauls preference order mentioned at the end) > 4. Keep all non-free-firmware packages in non-free too. This would be > backwards compatible, but may expose bugs in dak, debian-cd, apt and > other tools, so IIRC this has been vetoed by the archive and CD teams. > This also wouldn't result in users without non-free getting any of the > non-free firmware, which maybe we want since it is the new default? libapt or probably most user-facing client are no concern in this as packages coming from multiple sources is normal. If you have e.g. unstable and testing in your sources.list it is happening all the time, or you have multiple mirrors, … only by the virtue of having packages installed and somewhere online a client needs a way to figure out if the version installed is the same as (one of) the versions online and which online sources talk about the same version (naively, you would think version number is enough, but libapt actually goes beyond that). I assume through that in servers and other tools who are not usually exposed to packages in multiple versions or multiple sources in general have a harder time with this, so I can understand them being reluctant. There are also a lot of tools… most user-facing clients will be based on libapt or at least directly inspired by it, but if clients like (c)debootstrap expect a package name to be no longer unique in their world view (after all, they don't even do multi-sources like -updates and -security …) I honestly don't know and fear the worst. It is also that if we decide that, we basically decide that it will stay that way forever. Its also an (arguably tiny) waste of diskspace and such for everyone who has both components configured. It is the only solution treating everyone equal though. All the others talk only about sources.list with no idea if and how e.g. debootstrap needs to understand that non-free-firmware is a thing now. Does it? > 3. Add some code to apt to download non-free-firmware when non-free is > available in the sources and the downloaded Release files. This would > solve the issue for Debian and all other derivatives too, if they > decide to add a new non-free-firmware component too. This might not > be accepted by apt developers as it is kind of a hack to special-case > Debian component semantics in apt, although maybe a component mapping > config option would be accepted. This might result in extra Debian > support requests when users notice the new component in `apt update`. > This might not work for users of tools not based on apt, like cupt? > This wouldn't result in users without non-free getting any non-free > firmware though, which maybe we want since it is the new default? The problem with this within libapt is that libapt wants to look at the sources.list entry and produce a list of files which could possibly belong to this entry. The Release file is just one of those files. It is consulted later to remove entries from the file list (e.g. in an 'update'), but files aren't added at that stage. Think of 'apt update --print-uris': What would that print if it would need to look at the Release first? If you look closely, you will notice e.g. a line talking about 'binary-all/Packages'. The Release file will later tell apt to not download it for Debian. Similar, depending on your locale environment apt talks about downloading Translation files here which don't exist or perhaps even of Contents files which are in an other location than in reality for some distros (hello Ubuntu). So, if we wanted that, I could hardcode in apt that it should look for non-free-firmware, too, if it sees non-free as a component configured and decide later on not to download that component if it doesn't exist – on the upside (depending on your view) that isn't Debian specific. In practice it would probably turn out to be a medium sized patch as so far apt doesn't have the concept of an implicit component, but it shouldn't be rocket science and easily done ahead of the freeze. It would probably be too big for a backport through and even if very unlikely in practice a behaviour change as suddenly grabbing an existing non-free-firmware component and upgrades from it after an unattended upgrade in an unattended upgrade is… that rules out availability of the bookworm-version of firmware packages in the upgrade to bookworm. They would be installed only with the first 'update && upgrade' cycle on the upgraded bookworm system, potentially unattended. Most other "solutions" have the same "problem" – I would hope that for firmware packages it isn't really one in practice as they should be very light on (rev-)dependencies and demands upon them. We are potentially burning one component name forever, but I suppose we can live with that. The question is if we should do that through as it would be libapt- specific magic. I suppose as we are only talking about sources.list I guess we can do whatever as after all, that file is libapt-specific as well, but: Alice as an upgrader has non-free in its sources.list and gets non-free-firmware implicitly as a service from apt. Bob installs Debian on a fresh system and gets non-free-firmware in its sources.list as a service from d-i. Cecile is an upgrader, too, but she has non-free in her sources.list only for the firmware, so she would happily switch out non-free for non-free-firmware, if only she would know. All of them go online, read stuff potentially decades old about Debian, firmware and non-free. Their software center GUIs talk about four components now (do they?) they can enable (or not) in these funny little dialogs… As much as I would like apts sources.list to be apt-specific, I fear a bunch of things read and even write it, which potentially need to implement apt's magic as well to make sense to the user. Alice and Cecile will be confused if e.g. the GUI says they don't have non-free-firmware enabled, but they are getting packages from it… That is not to say no, I just want to highlight that other places would need some work as well and it could be confusing if we miss some – but then, what change isn't confusing. (That apt does things this way is due to historic grow. I entertain some changes which if they would exist would make similar split-offs work better, but those I would classify as requiring enormous patches. Absolutely not going to happen soon, if at all) > 1. Document it in the release notes and let users handle it. This means > lots of users won't get security updates for firmware (which are mostly > only issued for x86 CPU microcode), since lots of folks won't read the > release notes. This also means lots of support requests when users > can't find the firmware package they wanted. 'apt update' still has the code which detected Debian sources accessed via ftp, which told users that ftp will be shut down and points to a press release about it. [0] I didn't implement something similar for the security change as I somehow got the memo way too late and it would have been harder given in that case I would have no data to go by, but that is water under the bridge by now. We could do something similar to ftp here, detecting non-free but not non-free-firmware for a Debian source and point users to a press release explaining what this is all about (not the release notes, as e.g. sid users would somewhat rightly not expect to need to look there for information). That is somewhat trivial to do, we might even be able to convince the stable managers to allow backport this, so a bullseye user running 'apt update' while upgrading to bookworm would see that message already or otherwise be bugged about it IF they later interact with apt (which isn't a guarantee. So ideally other front ends would talk about this, too). That would be entirely Debian specific and hard-coded in apt (and in other front ends) though. I am not an enormous fan of producing an index of all repositories wanting to opt-in within apt source code. So moving that to an external hook might be better from a backport sense (as I suppose in the lifetime of stable, repositories will adapt. Not all prepare for stable while we do but against the finished product). I don't really want to rank either of the mentioned options as either could work, they all have their benefits and drawbacks and most importantly: while I am happy to impose work upon myself, I don't want to decide what others should work on. I also have a bad track-record of judging what is acceptable to bother users with… If I completely ignore the work aspect, for me personally I would favour 3 as it has the hint of introducing the concept of a hierarchy in components which might come in handy later if we want to split off other sections in other components as well. But as said, either works and I would be willing to support them from the apt side of things at least. With one exception: I rank any option even remotely considering a postinst failure well below NOTA as that is a horrible user experience. isa-support is a hack, not a role model. It is barely acceptable only because it effects only a tiny fraction of our user base so far. And even for those, I would like apt to help not installing broken packages (but that is another topic). So, who is gonna take the blame for deciding this for everyone? Best regards David Kalnischkies [0] https://salsa.debian.org/apt-team/apt/-/blob/main/apt-private/private-update.cc#L88-106
Attachment:
signature.asc
Description: PGP signature