I think this is working as intended.  cros-workon works by explicitly unmasking the -9999 version of an ebuild while masking all versions smaller than that: https://chromium.googlesource.com/chromiumos/chromite/+/master/lib/workon_helper.py#268.  So the package.mask file in chromiumos-overlay is overridden by the higher priority package.unmask directory in the board's sysroot:


(cr) chirantan@belgium ~/trunk/src/scripts (git-svn)-[chroot-update] % cros_workon-eve list
chromeos-base/chromeos-init
chromeos-base/crosh
chromeos-base/crosvm
chromeos-base/metrics
chromeos-base/vm_tools
sys-kernel/chromeos-kernel-4_4

(cr) chirantan@belgium ~/trunk/src/scripts (git-svn)-[chroot-update] % cat /mnt/host/source/.config/cros_workon/eve
=sys-kernel/chromeos-kernel-4_4-9999
=chromeos-base/metrics-9999
=chromeos-base/crosvm-9999
=chromeos-base/chromeos-init-9999
=chromeos-base/vm_tools-9999
=chromeos-base/crosh-9999

(cr) chirantan@belgium ~/trunk/src/scripts (git-svn)-[chroot-update] % cat /mnt/host/source/.config/cros_workon/eve.mask
<sys-kernel/chromeos-kernel-4_4-9999
<chromeos-base/metrics-9999
<chromeos-base/crosvm-9999
<chromeos-base/chromeos-init-9999
<chromeos-base/vm_tools-9999
<chromeos-base/crosh-9999

(cr) chirantan@belgium ~/trunk/src/scripts (git-svn)-[chroot-update] % l /build/eve/etc/portage/package.unmask
total 0
lrwxrwxrwx 1 root root 40 Apr 11 14:46 cros-workon -> /mnt/host/source/.config/cros_workon/eve

(cr) chirantan@belgium ~/trunk/src/scripts (git-svn)-[chroot-update] % l /build/eve/etc/portage/package.mask
total 0
lrwxrwxrwx 1 root root 45 Apr 11 14:46 cros-workon -> /mnt/host/source/.config/cros_workon/eve.mask

So how does one properly handle something like bug 831025? If I cros_workon hostapd or wpa_supplicant for gale or whirlwind testbed-ap, it seems arbitrary as to which one I'll get -- jetstream's version or chromiumos's version. I guess I can always be sure to emerge with a ::chromiumos suffix, but that's tricky and means I can't rely on build_packages at that point...

e.g., for gale --profile=testbed-ap:

emerge-gale net-wireless/hostapd::chromiumos

I don't know of a good answer for that.  I'm guessing that when we wrote cros_workon we never intended for packages that use it to also be masked via the normal method.

Maybe we can change the name of the package to something like hostapd-jetstream, add it to target-chromium-os in the jestream overlay, and then add hostapd to the package.provided file.  It's hacky but I can't really think of a better way right now.

OK, thanks. Since this is likely only biting people like me (specifically around jetstream-like platforms where we don't want to use jetstream software), I'll assign to me, with the expectation that I'll likely only try this if it gets really annoying.

yeah, Chirantan covered it all well.  we've exceeded original design goals quite a bit when it comes to cros-workon.

before writing the package.unmask entry, we could have it query the overlay where the current version is visible from, and then we include that in our package.unmask line.  i think that'd address scenarios like issue 831025.