DEFAULTREPO is not env-overridable

[bureado]

distri env outputs three variables today.

Unlike DISTRIROOT and DISTRICFG, which do respond to environment, DEFAULTREPO is hardcoded today as DISTRIROOT + build/distri/pkg.

The build/distri/pkg path isn't shipped in the git repo today. So if it's expected to be an immutable convention it should be generated automatically by commands such as distri build or distri scaffold. distri scaffold creates build/<pkg> but right now, distri build fails to create any build/distri paths:

-sh-4.4# distri build 
2019/08/25 22:52:36 building nano-amd64-4.3-1
2019/08/25 22:52:36 verifying nano-4.3.tar.gz
build: build: builddeps: package "bash" not found (pattern /root/distri/build/distri/pkg/bash-amd64-*.meta.textproto)

Furthermore, it might be appropriate to use the local store for the pkg/ path, for example:

mkdir -p ~/distri/build/distri/pkg 
mkdir -p ~/distri/build/distri/debug # also not created by `distri build`
cp --link /roimg/* ~/distri/build/distri/pkg/

IMHO, distri env shouldn't output variables that can't be overriden. I think it's probably OK to have DefaultRepoRoot + /pkg hardcoded (although a bit confusing with pkg/ in the main repo for sources) but then DefaultRepo[Root] need to be handled just like DistriRoot and DistriConfig.

It's also unclear to me why DefaultRepo and DefaultRepoRoot are split, but I see some usage across the code that probably needs to be harmonized before any changes, or they should both be environment variables.

[stapelberg]

Thanks for filing this!

The build/distri/pkg path isn't shipped in the git repo today. So if it's expected to be an immutable convention it should be generated automatically by commands such as distri build or distri scaffold.

It should indeed by created by distri build.

Furthermore, it might be appropriate to use the local store for the pkg/ path, for example:

Sometimes, yes. I can think of situations where it wouldn’t be helpful: when you are running something else (e.g. an older release of distri, trying to build a newer one). In other situations, it might even be harmful: suppose you modified a package on your local system without bumping the revision number.

I think the safer approach is to allow users to (lazily) populate these directories. Perhaps distri build should fetch all the build dependencies, whereas distri batch actually builds them (but should fetch the bootstrap dependencies).

It's also unclear to me why DefaultRepo and DefaultRepoRoot are split, but I see some usage across the code that probably needs to be harmonized before any changes, or they should both be environment variables.

Agreed!