distro specific build/runtime deps

[christophprokop]

At the moment build/runtime deps are configured across all distros/images.
Sometimes this leads to more packaging than needed.
Let's say a library is only needed on our oldest base image.
With the current config all other would depend on this library as well (though the system package would be sufficient).
That contradicts that we don't want to provide an "opensoftware linux distro" but deliver only packages that a certain distro+version lacks.

[primeos-work]

Good idea. Butido currently lacks the concept of distros (s. also #185 (comment)) but IMO it's quite essential for a proper distro/OS independent package build tool to support distro/OS specific configurations.

I'm not sure how to best address this though. Distro specific build/runtime deps should be fairly easy to achieve but I wonder if that's enough as we might also need different configure/compile/etc. flags (depending on the distro), which would require a generic solution (that could ideally be used everywhere - but I don't (immediately) see a good solution for that with TOML files). However, as long as the only use case is to take a dependency from butido's package repo or the system, it should be possible to ignore the rest (although it'd make sense to then make the OS/system packages conditional as well).

Any concepts/ideas/suggestions what the usage should look like (TOML example)?
It might make sense to use regex patterns/matching to avoid potentially long lists.
We could theoretically also match against the container image names instead of additional OS information that would have to be added first.

Maybe something roughly like this?:

[docker]
images = [
  { name = "local:sles15-default", short_name ="sles15" },
  { name = "local:deb11-default", short_name ="deb11" },
  { name = "local:deb12-default", short_name ="deb12" },
]

---

[dependencies]
runtime = ["foo =1.2.3"]
build   = [("example =1.2.3", "deb*") ("bar =1.2.3", "sles15")]  

I haven't thought much about the design yet, that's just the first thing that came to mind. Unfortunately TOML doesn't support tuples so we have to think of a proper design anyway (the tuples could be replaced with inline tables, which should make it easier to read and understand (for outsiders/newcomers) but the "code" would be longer (character count) and probably more annoying to write).
We should also try to keep the design backward-compatible (in my draft above "foo =1.2.3" could expand to ("foo =1.2.3", "*") so that users aren't required to change almost all of their files in the packages repo.

[primeos-work]

Distro specific build/runtime deps should be fairly easy to achieve but I wonder if that's enough as we might also need different configure/compile/etc. flags (depending on the distro), which would require a generic solution (that could ideally be used everywhere - but I don't (immediately) see a good solution for that with TOML files).

Brief update: Due to additional customization requirements and the constraints of TOML, we decided to try this out via a preprocessor (and if it works out well, we could theoretically integrate (parts of) it into butido).