supporting installation of extra utils in non-release images

[Mike Frysinger]

devs constantly want "more stuff" when creating dev or test images.
this falls into two categories:
- extra packages (i.e. ones that'd never be installed into a release
image e.g. strace)
- extra utils in a package (i.e. the bluez package installs libs we
want in the release image, but it also includes test apps which don't
belong in the release image)

the first case can be handled easily today globally via the
chromeos-dev package, and overlays can additionally add their own by
overriding the virtual/chromeos-bsp-dev package. anything that is
listed as a dependency of these packages are added to dev/test images
only.

the second case has been a source of pain for many. the workaround we
have atm is to manually split the package into an extra "xxx-utils"
which takes care of installing just the extra junk. but this is a
pain to scale when things like patches/build magic needs to be copied
between ebuilds.

since we can't support building the same package atm with different
USE flags, two possible ideas for keeping packages merged:
(1) add a new convention: install your extra stuff into /usr/local.
we'd update the build_image script to take care of discarding anything
in that path when creating the release image, but keeping it for the
dev/test images.
(2) list the extra utils in INSTALL_MASK in
chromeos/config/env/$CATEGORY/$PN and add the package to chromeos-dev.
this way the utils would get masked from /usr/bin/xxx, but would
automatically show up in /usr/local/usr/bin/xxx. the downside here is
that you'd also duplicate other files from the package in / and
/usr/local, but i'm not sure that's a big deal.

to be clear, this would not help with building a single program with
different functionality. for example, you still wouldn't be able to
build say curl with USE=-ldap for the release image and USE=ldap for
the dev/test image (since you're changing the generated code). this
would only help with adding extra files to the dev/test images.
-mike

[Chris Masone]

1) sounds like it sucks less :-)  I guess it kinda depends on the particulars of the ebuild for the package in question, but it sounds less magical and requires less copypasta.

[Vadim Bendebury]

On Fri, Apr 20, 2012 at 2:26 PM, Mike Frysinger <vap...@chromium.org> wrote:

yet another way is to disable dm-verity and mount root file system rw,
some think it is too far from the intended mode of operation, but it
sure speeds up development...

cheers,
/vb

> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Scott James Remnant]

This isn't useful when sending images to partners

In my case, the programs we needed to add to test images were necessary parts of the image for remote testing

Scott

[Chris Masone]

On Fri, Apr 20, 2012 at 4:04 PM, Vadim Bendebury <vbe...@chromium.org> wrote:

This is not the use case Mike is trying to solve.  In the case of NSS, we need the utils automatically installed on all test images that go to the test lab, but we don't want them on the release images.

[Chris Sosa]

As cmasone noted, this does sound like it sucks less and currently
matches with the stateful dev logic i.e. everything in /usr/local is
not included in release images as they live in stateful.

The bigger problem is that many tools just won't work out of the box
from /usr/local/bin so they may require adjustments.

>> > (2) list the extra utils in INSTALL_MASK in
>> > chromeos/config/env/$CATEGORY/$PN and add the package to chromeos-dev.
>> >  this way the utils would get masked from /usr/bin/xxx, but would
>> > automatically show up in /usr/local/usr/bin/xxx.  the downside here is
>> > that you'd also duplicate other files from the package in / and
>> > /usr/local, but i'm not sure that's a big deal.

FYI this ends up being the same path on a Chrome OS dev/test image.