target-os vs target-os-dev and target-os-test

[Thiemo Nagel]

Hi folks,

as a way to determine which packages are included in base, dev and test images I've been looking (*) at the dependencies of target-os, target-os-dev and target-os-test. Surprisingly (to me) the base image includes way more packages than either dev or test images:

701   target-os
413   target-os-dev
551   target-os-test

Naively I'd have assumed for dev and test images to be exact supersets of base. Could somebody explain why this isn't the case? (I've used BOARD=lulu, but other boards I've tried look similar.)

Thank you,

Thiemo

(*) Following these instructions I've used this command:

for PKG in target-os{,-dev,-test}; do parallel_emerge --pretend --emptytree --board=$BOARD virtual/$PKG | grep -e '^\[' | cut -c18- | cut -f1 -d' ' | sort > DEPS.$BOARD.$PKG; done

[Mike Frysinger]

they are treated as supersets.  our build system guarantees that one is not installed until the underlying one already has been.  i.e. test can assume base & dev, dev can assume base.

-mike

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

[Thiemo Nagel]

Thank you, Mike! Afaics this isn't expressed as explicit dependencies in the relevant ebuilds, though? What's the reason for that?

[Mike Frysinger]

there are no explicit deps for it.  i don't see a need to add one as it doesn't add any value or correct any missing deps, but it would increase the depgraph for both considerably and slow things down.

what is your underlying concern here ?

-mike

[Thiemo Nagel]

+Aysu Sayın fyi

No concern really, just trying to understand how things are working. The lack of dependency had tripped me up and I was wondering whether my understanding that dev is a superset of base was wrong. Thanks for clearing this up! (I'll send a CL to add a bit of documentation.)

[Mike Frysinger]

if we wanted to argue ideological purity, you'd certainly be correct that we should add virtual/target-os to virtual/target-os-dev, and virtual/target-os & virtual/target-os-dev to virtual/target-os-test.  but since i'm only seeing practical downsides here, and it's how we've handled these targets since the start of the project, i'm inclined to leave it be.

not that "it's always been that way" is an argument to not change ... i highlight it more in the vein that it hasn't caused us troubles , so why kick the poor dog if it's not bothering anyone ? :)

-mike

[Thiemo Nagel]

I'm not arguing. It seems perfectly reasonable to me for practicality to win over ideological purity. :) 

Adding a bit of documentation: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1742129