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.? Cheers! -- Santiago
Attachment:
signature.asc
Description: PGP signature