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
On Fri, Apr 20, 2012 at 2:26 PM, Mike Frysinger <vap...@chromium.org> wrote: > 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
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.
On Fri, Apr 20, 2012 at 2:26 PM, Mike Frysinger <vap...@chromium.org> wrote: > 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
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...
> On Fri, Apr 20, 2012 at 2:26 PM, Mike Frysinger <vap...@chromium.org> > wrote: > > 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
> 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...
> On Fri, Apr 20, 2012 at 2:26 PM, Mike Frysinger <vap...@chromium.org> > wrote: > > 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
> 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...
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.
On Fri, Apr 20, 2012 at 4:17 PM, Chris Masone <cmas...@chromium.org> wrote:
> On Fri, Apr 20, 2012 at 4:04 PM, Vadim Bendebury <vben...@chromium.org> > wrote:
>> On Fri, Apr 20, 2012 at 2:26 PM, Mike Frysinger <vap...@chromium.org> >> wrote: >> > 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.
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.
>> > 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
>> 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...
> 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.
