On Tue, 2022-05-10 at 14:30 -0600, Sam Hartman wrote: > So let's assume that at least all those packages can move to > non-free-firmware. For backwards compatibility, I think that the firmware component is going to need to be a subset of non-free; i.e. packages are going to need to be *copied* not moved from non-free to the firmware component, which means they would be available from both non-free components. Otherwise users who currently have firmware packages installed from non-free will not get (security) updates unless they know about the switch to the new component. Security updates for the CPU firmware available in the *-microcode packages are usually very important. There are going to be many users who don't read the firmware announcement and don't read any release notes about the change. I also feel like firmware is more like a section of non-free than an entirely different type of software licensing, which making it a completely separate component like non-free-firmware implies. Since the component is going to need to be a subset of non-free rather than separate to non-free, I suggest the name "non-free/firmware", which aims to indicate to everyone who sees it that firmware is a part of non-free that has been copied out to allow for extra separation. If we make firmware just an extra archive section that happens to also create an extra component, then creating it will be simple, ftp-masters just need to change the overrides for source packages that build firmware-* and *-microcode binary packages from whatever section they are in now to firmware (in main) and non-free/firmware. The firmware in main section would of course not have the extra split out component. > Build Dependencies > ================== Even lots of the free firmware in main is not built from source in Debian, so I don't think this will be a problem for non-free firmware, it will pretty much never have source code. https://wiki.debian.org/Firmware/Open The only exception is things like firmware-sof-signed, which is libre firmware except the binaries are built and signed by Intel, so Debian can't build the firmware binaries ourselves, unless the approach taken with the Secure Boot shim signing is possible. First reproducibly build the binaries, then if they match Intel's signature, attach Intel's sig. That relies on Intel using the same cross-compiler as Debian though. If build-deps do become a problem, the section proposal above neatly solves this, since non-free firmware remains in non-free and can build against packages in on non-free/contrib as usual. > Binary Dependencies > =================== > > It's possible that packages in non-free-firmware could depend on > non-free libraries or downloader tools or whatever. Some of the firmware-* packages in non-free do not contain firmware, they are only downloaders/extractors for non-redistributable firmware, so it wouldn't surprise me if this happens. > As examples to consider, do we want to include the following in our > practical divergence from software freedom purity? Since clearly there will always be users with install use-cases that aren't covered by main or even main plus non-free/firmware, perhaps we should have multiple sets of images for different audiences with different sets of non-free things? Each of them would explain what is non-free and the consequences of that both on the page itself and in prompts within the image itself. The download page could then direct the people to the right images for them; see my proposal in the other thread for how that might work. https://lists.debian.org/msgid-search/683a7c0e69b081aae8c46bd4027bf7537475624a.camel@debian.org > * Machine learning models for speech that would make it easier for > people who cannot easily type to use Debian. This is covered by Free Software, so should not need to go into the non-free part of the archive. OTOH Debian doesn't have GPU/TPU infrastructure so maybe can't train models for Debian main. https://coqui.ai/ ;(formerly Mozilla DeepSpeech) https://kaldi-asr.org/ > Whatever it is, I'd be very appreciative if we could take some time > to come up with guidelines rather than firmware vs not. I think this is an "I know it when I see it" type of situation and I think we can trust the ftp-masters to set the overrides correctly so that the packages that are firmware end up in the right place. Since most of the packages named *firmware* *-microcode actually contain firmware, that would be a reasonable initial list, as would anything that puts files in the /lib/firmware/ directory. Some of the packages (like firmware-siano) are not in any way needed by the Debian installation process, despite containing firmware according to reasonable definitions of that. They aren't needed for basic functionality of a system either, just for specialised things (receiving TV signals for eg). So they very likely aren't needed on the non-free/firmware images and thus aren't needed in non-free/firmware? -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part