On Sun, 24 Jun 2012, Ben Hutchings wrote: > 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.
Uh? I failed at attempting it, it aborts complaining that it cannot find something in (base, microcode), (base, cpu-x86-amd), etc. And it only runs after I install the -support package, as it wants python modules that are in there. > > 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. It was not enough to get it to run, but maybe I did something wrong. Help is appreciated (or a pointer to the documentation for how to work with firmware-nonfree). > > 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. Other than the lack of a README.source to avoid it? Maybe. But at the end of the day, the fact is that I still don't know how to get firmware-nonfree to do what I need it to :-( -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120624160531.ga3...@khazad-dum.debian.net
