On 07/27/2015 10:14 AM, Loucaides, John wrote:
> I think it's a great idea to play with packaging, but as you
mentioned, I do have some
> concerns about the driver. Your idea to play with this without
submitting to a real
> repository seems good. [...]

Thanks for input. I'm a newbie at Debian packaging, so I expect you'll
have plenty of time to create more concise warning text. :-)

I'm getting start with private packaging. I'll file an Intent-To-Package
bug against Debian shortly.

Changes to D-I (Debian Installer) is a much larger effort, and would be
later. I have no idea if D-I team would have an interest in a patch with
this kind of feature yet.


Also, while on this thread, I received a few answers to my Debian
packaging questions:

> I don't understand how to address
> packaging of drivers that do post-boot Linux module loading. From what
> I gather, this ability would likely be disabled on more secure systems
> (where CHIPSEC might want to be used).

AFAIK the only way to load modules after the next boot following package
installation is to add it as part of the packages' installed init
scripts. Using init to manage any CHIPSEC binaries that need to have
things happen after they exit (i.e., unloading the kernel driver) might
be a good idea.

> perhaps the
> CHIPSEC driver package should display the contents of CHIPSEC's
> warning.txt and let the use agree to this security risk, before
> installing? If so, I need to find out how to do that in a Debian
> package.

The `debconf` program can handle cases like this. It's normally used for
install-time conditional package configuration (it's the thing that asks
questions during the d-i process: the keyboard configuration, static or
dynamic network addressing, etc. all are instances of debconf
configuring a specific package.)

Joey Hess' debconf tutorial is here:
http://www.fifi.org/doc/debconf-doc/tutorial.html

> Since CHIPSEC will only work on Intel x86/x64 systems, and not
> AMD-based
> AMD64 systems, installation has to check CPU and only install on
> proper
> systems. I'm unclear how to do this check in a Debian package.

Debian calls all the consumer-grade 64-bit arches `amd64` whether the
vendor is Intel or AMD; ia64 is the name for Itanium-based Intel 64-bit
chips. If CHIPSEC doesn't work on ia64 then it's a simple matter of not
providing a package for that arch, since Debian keeps separate archives
for each arch.