On Sun, 2012-06-24 at 12:21 -0300, Henrique de Moraes Holschuh wrote: > On Sat, 23 Jun 2012, Ben Hutchings wrote: > > > > The package template system currently only supports one optional > > > > postinst action, but it wouldn't be hard to extend to add others. > > Ok, I tried to ship the microcode for amd processors using firmware-nonfree. > There are a few problems: > > 1. firmware-nonfree seems to be very tightly tied to module names. We'd > need to join all microcode upstream packages under "microcode" which is the > module name. This is not a good thing IMO. No such tying is required. > 2. firmware-nonfree simply doesn't want to work without MODULE_FIRMWARE > support in the official kernel-image, that somehow migrates to magic binary > dumps in the -support package for that image, that gets used by > firmware-nonfree to generate its own metadata. Yikes! I don't know where you get this idea, as there is no such information in linux-support-<version>. The set of files to be included in firmware-foo is specified by foo/defines. > 3. firmware-nonfree _really_ needs a README.source :-) Yeah. > So, I am stumped. Assuming it is simply not a matter of me not groking how > to shoehorn firmware-nonfree to do what I need, at this point, it either > means we need some changes to firmware-nonfree so that it can ALSO work as a > generic multi-upstream dumping ground for stuff that does not benefit from > (or actively gets harmed by) the automation it currently does, or that we > should have separate source packages for such stuff, and leave > firmware-nonfree for regular firmware that fits well with the automation it > currently implements. > > Any ideas? I think it might be better in the long term to split up firmware-nonfree and provide a dh_firmware used by multiple source packages. But I think you are seeing obstacles that don't exist. Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure.
Attachment:
signature.asc
Description: This is a digitally signed message part