MIR: explain when a MIR is needed

[cpaelzer]

Fixes: #42

[s-makin]

Just some nits :)

[cpaelzer]

Just some nits :)

Thanks for the review @s-makin , it helped me to undertand the ref/[] and term usage better - and your wording was obviously better than mine. All integrated now!

[s-makin]

LGTM :) thanks for the changes

[setharnold]

The boost* family of packages might not be 'runtime' dependencies but I believe we'd expect them to go through the MIR process if they were to be part of building a main package.

Can we capture this idea?

[cpaelzer]

The boost* family of packages might not be 'runtime' dependencies but I believe we'd expect them to go through the MIR process if they were to be part of building a main package.

Can we capture this idea?

Hi @setharnold , but we only do expect those that end in code that runs at runtime.
Maybe we should work on a list of examples to make this more clear and then add that to this PR?

• a) classic -dev packages - leads to runtime dependencies - needed
• b) rust/golang dev packages - not runtime dependencies eventually, but code that runs - needed
• c) Sphinx-whatever to build docs - build dependencies, not resulting in code that is ran - not needed

Where is boost there?
I'd expect it to just be case (a) right? Or are these headers that become macros and will be used in code, but not have a runtime dep?
Also what else would you suggest to extend the list by?

Also FYI: rebased to adapt to latest changes in the repo

[slyon]

IMO this PR is good as-is.

I agree we can further improve/refine that section telling about packages that are generating code used elswere in "main" should go through MIR, too. But that might be a separate PR.

[setharnold]

My recollection of the boost family of useful things are headers that are compiled into the project much like golang code. It executes actual code on user computers but doesn't show up in Depends: lines, only Build-Depends: lines.

[cpaelzer]

Also from meeting - Lukas Märdian (slyon):

Just gave my +1 on this (IMO is good as-is). But: I agree we can further improve/refine that section telling about packages that are generating code used elswere in "main" should go through MIR, too. But that might be a separate PR.

I was thinking mostly about compilers, like GCC or Rustc. They are not really a runtime dependency of anything, but we certainly what to have them supported in "main"
because they can heavily influence anything in that pocket

[cpaelzer]

OK, with that I can refine it

[setharnold]

The compilers is a good thought, which toolchains are available in which releases places constraints on what the Ubuntu Security Team can maintain.

[cpaelzer]

@setharnold the last paragraph now goes into more detail of these "not a dependency but code that runs".
Could you check if it now addresses what you wanted to see?