On Thu, 2012-11-08 at 02:35 +0200, Adrian Fita wrote: > On 08/11/12 01:44, Ben Hutchings wrote: > > On Wed, Nov 07, 2012 at 04:33:00PM -0200, Henrique de Moraes Holschuh wrote: > >> On Wed, 07 Nov 2012, Adrian Fita wrote: > >>> Fair enough, but how about having the linux-image packages recommend the > >>> *microcode packages for installation so users won't get confused by the > >>> message caused by the module trying to load the file with the microcode > >>> update and not finding it? > >> > >> I don't think we can do that, because the -microcode packages are in > >> non-free. > >> > >> And an annoying technical detail makes it suboptimal to add the microcode > >> packages as a recommendation of the firmware-linux-nonfree package. > > > > ...which is that dpkg does not support architecture-specific relations > > in binary packages. > > Sorry if I don't understand what you're talking about... I was expanding on Henrique's second point. > I was thinking > about adding the *microcode to the recommends/suggests for the x86/amd64 > kernel packages only (here's some of the packages that my system lists > for these architecures: linux-image-486, linux-image-686, > linux-image-686-pae, linux-image-amd64, linux-image-rt-686-pae). I don't > think this needs any kind of special architecture-specific support in > dpkg... http://www.debian.org/doc/debian-policy/ch-archive.html#s-main "... packages in main ... must not require or recommend a package outside of main for compilation or execution" Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong.
Attachment:
signature.asc
Description: This is a digitally signed message part