Currently we have all our elements and library files in a top-level
directory and install them into
<root>/share/diskimage-builder/[elements|lib] (where root is either /
or the root of a virtualenv).
The problem with this is that editable/development installs (pip -e)
do *not* install data_files. Thus we have no canonical location to
look for elements -- leading to the various odd things we do such as a
whole bunch of guessing at the top of disk-image-create and having a
special test-loader in tests/test_elements.py so we can run python
unit tests on those elements that have it.
data_files is really the wrong thing to use for what are essentially
assets of the program. data_files install works well for things like
config-files, init.d files or dropping documentation files.
By moving the elements under the diskimage_builder package, we always
know where they are relative to where we import from. In fact,
pkg_resources has an api for this which we wrap in the new
diskimage_builder/paths.py helper [1].
We use this helper to find the correct path in the couple of places we
need to find the base-elements dir, and for the paths to import the
library shell functions.
Elements such as svc-map and pkg-map include python unit-tests, which
we do not need tests/test_elements.py to special-case load any more.
They just get found automatically by the normal subunit loader.
I have a follow-on change (I69ca3d26fede0506a6353c077c69f735c8d84d28)
to move disk-image-create to a regular python entry-point.
Unfortunately, this has to move to work with setuptools. You'd think
a symlink under diskimage_builder/[elements|lib] would work, but it
doesn't.
[1] this API handles stuff like getting files out of .zip archive
modules, which we don't do. Essentially for us it's returning
__file__.
Change-Id: I5e3e3c97f385b1a4ff2031a161a55b231895df5b
If we are booting pxe booting using syslinux, and it has IPAPPEND 2 in
the boot stanza, then it will append the mac address of the device we
are booting from to the kernel parameters where we can get at it
pretty easily.
If we are booting physical hardware via UEFI over the network, we can
rely on the BootCurrent EFI variable to point at the boot entry for
the NIC we booted from, which will include the MAC address of that
nic.
If neither of those cases are in play, we can just fall back to the
all-physical-devices-with-links code.
This currently uses the Bash 4 support for associative arrays to handle
the netboot-in-UEFI case, if needed I can rewrite it to be Bash 3 compatible.
Change-Id: I5e50e30c60d6d732a09ab61251cbb9be08bb6113
We assemble the init script of ramdisks with the fragments from included
elements, alphabetically.
We now place leading numbers on all of the fragments we ship, to make it
more obvious to element authors and downstream users, how the process
works.
Closes-Bug: #1251706
Change-Id: I56b0d42971c8c462eddcfe1769f8124405e1233c
2013-11-15 17:18:34 +00:00
Renamed from elements/hwdiscovery/init.d/hwdiscovery (Browse further)
