DL_DIR in local_conf_header doesn't work anymore with kas-container 2.5

[vivien]

PermissionError: [Errno 13] Permission denied: '/downloads'

[jan-kiszka]

OK... or rather not ok. I'm afraid we need to think about how to establish testing for kas-container.

Let me check what went wrong here.

[vivien]

It looks like since 2.5, the repo is mounted read-only by default for build, hence the permission denied. The problem is that some configuration like these could be added in local_conf_header before. Using the DL_DIR environment variable works.

[jan-kiszka]

Works for me, though - can you provide more details on how to reproduce?

[jan-kiszka]

Ah, local_conf_header... that may explain why some random DL_DIR may not be writeable if it is under repo, but not repo/build. But I do not see yet why this should have worked before - likely - 06240c23da6e8fc23146cf8e6814efbd5a08e5d7.

[vivien]

with kas-container build the repo is mounted read-only. If the DL_DIR is stated inside the local_conf_header, the script does not explicitly know about it (as opposed to passing DL_DIR via the environment which adds a rw volume) and thus the directory (${TOPDIR}/../downloads in my case) ends up being read-only.

[jan-kiszka]

Yes, but it was mounted read-only before as well. So, the situation you describe is real, but not new. And I'm also not sure if we can resolve it automatically without more and more logic in that "simple" kas-container script.

If your project chooses a location that is output of build - or even absolute and outside of repo -, it's on its own ground. For anything inside of repo, you can at least help out and provide --repo-rw. But how should kas-container know that upfront?

[vivien]

I agree, assuming that repo is mounted read-only is a good idea, it's a layer after all. I'm just pointing out that I was successfully using DL_DIR = "${TOPDIR}/../downloads" up to 2.4, which now doesn't work with 2.5. I'm fine with this being deprecated if that is explicitly stated somewhere in the doc, since I might not be the only one encountering this with the new release.

[jan-kiszka]

As I pointed out, this is no change in behaviour. Already 2.4 rejected

local_conf_header:
  dldir: |
    DL_DIR = "${TOPDIR}/../downloads"

Just tested and confirmed that. No surprise: This puts things under repo/downloads, rather than build/downloads. And repo is :ro since day 1 (6aa0336d366d1e8c0f0c00569ba739fd5e638871).

[vivien]

Very strange that it worked for me until 2.5! Anyway, the point is that DL_DIR in local_conf_header is not kas-friendly, now it's clear.