On Fri, Oct 14, 2022 at 10:52:01AM +0200, Santiago Ruano Rincón wrote: > El 14/10/22 a las 13:32, Paul Wise escribió: > > 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: > > > > 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. > > > > 2. Add some code somewhere to automatically modify the apt sources, > > somehow ensure that code is run by all Debian users and hope that other > > automated processes (like ansible/puppet) don't overwrite those changes > > and hope that users aren't storing apt sources config in packages, > > which would mean conffile prompts after the modification happens. > > > > 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? > > > > 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? > > > > Personally I would choose 4 first, I expect any potential issues could > > be easily fixed before the freeze. Next I would choose 3. Next I would > > choose 1 because I think /etc belongs to the sysadmin not packages. > > 5. transitional packages along with a helper package (that fails or > success during install) to prompt the user so they add non-free-firmware > section when needed. > > Is there any reason why you are not considering 5.?
Do you mean having packages with the same names, but different versions (even if only Debian revisions) and totally different contents, and also built from different source packages, in different sections of the same suite in the archive?... I'm... I'm not sure this would work... I think that others already expressed some doubts as to how dak would handle that. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
