i can't reproduce over here

$ ./setup_board --board=kevin --force --skip_chroot_upgrade
$ portageq-kevin envvar ACCEPT_LICENSE
* -@EULA @CHROMEOS
$ ./setup_board --accept_licenses="Google-TOS" --board=kevin --force --skip_chroot_upgrade
$ portageq-kevin envvar ACCEPT_LICENSE
* -@EULA -@CHROMEOS Google-TOS

Hmm, I'll give it a try again soon and close this if I can't either.

I probably did something wrong. I know at some point I was doing --accept_license= (missing the plural) but I'm pretty sure that wasn't what caused me to file this. I'll reopen if I see this again.

Hmm, so I'm seeing this again. It looks like /build/${BOARD}/etc/make.conf.board is actually getting overwritten in certain circumstances.

Steps:
1. ./setup_board --board=kevin
2. ./build_packages --board=kevin
3. ./setup_board --board=kevin --accept_licenses="Google-TOS" --force
4. ./build_packages --board=kevin

After steps 1, 2, and 3, either of the following return expected results:

portageq-kevin envvar ACCEPT_LICENSE
grep ACCEPT_LICENSE /build/kevin/etc/make.conf.board

But after step 4, it seems that make.conf.board reverts to the non-accepting form.

--accept_licenses is an option to build_packages too.  when the options were written, it was expected you would use the flag all the time (or really, not at all).

also, we really don't want people running setup_board+build_packages as it's pretty pointless -- build_packages does all of this for you.

> --accept_licenses is an option to build_packages too.

Well, it's all nice and confusing when it's intentionally not documented in --help.

> it was expected you would use the flag all the time (or really, not at all).

If you're not expecting anyone to use --accept_licenses, then what *is* a good way to build public checkouts of something that uses stuff under the Google-TOS license? Is this the best word?

https://www.chromium.org/chromium-os/licensing/building-a-distro

I recall trying to follow that previously, and at least one of the 4 bulleted recommendations didn't work as expected (I think the 2nd and 3rd? I'll give it a try).

Also, personally, I'd like to be able to configure by board once, then expect that future ./build_packages wouldn't clobber it. This behavior defies my expectations here.

> also, we really don't want people running setup_board+build_packages as it's pretty pointless -- build_packages does all of this for you.

Sure, but you might want to update the Developer Guide if you really expect that this is followed. It still mentions setup_board.

Also, the current scenario seems to be exactly the situation where one might want to setup_board and then later build_packages; if a developer hasn't figured out the magic hidden --accept_licenses= flag, then they might want to setup_board (including /build/${BOARD}/etc/make.conf.user) and then tweak ACCEPT_LICENSE before building.

because of the licensing aspect, we provide tips, but in the end it's not our problem to understand how licensing works.  that guide is the only one that exists and we don't intend to expand it much more.  it does specifically say "pass --accept_licenses when running build_packages" though, not setup_board.

as for the developer guide, it's a wiki that any @chromium.org can edit, and we don't have "owners" per-se for documents.  so the setup_board section can get trimmed by anyone who notices that it's still sticking around.

there shouldn't be a need to setup_board, mess with ACCEPT_LICENSE, then run build_packages.  just run build_packages with the --accept_licenses flag.  if that doesn't work, then we can fix that.

i hesitate to try and make setup_board preserve previous values when we don't do that much already, and it's hard to differentiate not-specified with they-passed-""-explicitly.

if you want to add an aside to the help text like "(must always be set)", that'd be fine.

I made small tweaks to the Licensing and Developer Guide pages.

setup_board is an otherwise persistent step (i.e., you only need to run it once), so it misled me into thinking its flag arguments would persist too. (Because, why not? Why wouldn't make.conf.user be auto-generated exactly once?)

Seeing this flag on build_packages would be more of a tip-off that it's not persistent (despite it getting written to disk). But I didn't actually notice that until recently.

Personally, this seems like really weird "WAI" behavior. Why is this written to make.conf.user at all if it's not going to act much better than "export ACCEPT_LICENSE=..."?

> if you want to add an aside to the help text like "(must always be set)", that'd be fine.

To the help text that is intentionally not printed anywhere? :D

i disagree about the persistence aspect being unexpected, but the accept licenses flag isn't the only piece of data that is transient here.  there's a few other settings that get stuffed every time.

setup_board/board_packages don't write ACCEPT_LICENSE to make.conf.user.  maybe you're confusing steps there ?  make.conf.user is explicitly "this is for the user only and no scripts ever touch it".

wrt --help not being complete, this was a decision we made a while ago to cut down on too many options and scripts.  we were drowning in diff ways to do the same thing, and exposing too many bits that shouldn't be exposed.  we still have too many scripts/workflows and endeavor to cut them out where possible.  you could probably argue that --accept_licenses should be promoted to a user visible flag via --help.  and i'd prob approve that CL ;).

> there's a few other settings that get stuffed every time.

What sort of settings are you referring to? I don't use many flags on setup_board.

> setup_board/board_packages don't write ACCEPT_LICENSE to make.conf.user.  maybe you're confusing steps there ?  make.conf.user is explicitly "this is for the user only and no scripts ever touch it".

Sorry, I meant make.conf.board.

> we still have too many scripts/workflows and endeavor to cut them out where possible.

I know the feeling.

> you could probably argue that --accept_licenses should be promoted to a user visible flag via --help.  and i'd prob approve that CL ;).

I'll consider that.

> What sort of settings are you referring to? I don't use many flags on setup_board.

sure, and most people don't use --accept_licenses ;).  i mean all the settings that setup_board takes as inputs and generates the output config files, and that board_packages also tweaks.

chances are it'll stay this way and then just get "fixed" as we rewrite/throw out src/scripts/.