IMHO:
Igor Gnatenko wrote:
* Do we want to support "buildroot-only" packages?
No, because this contradicts both the transparency expected from a
community-developed project and the self-hosting expectations.
* Do we want to build streams against all combinations (aka
py{2,3}+nodejs{8,9,10}+fedora{30,31,32} would result into 18 builds of
a packages)?
For modules that depend on both Python and NodeJS, that is what it would
boil up to indeed. And it should be clear that this does not scale. This was
one of the inherent design issues I had pointed out with Modularity from day
one: the promise that you can pick&choose arbitrary versions to mix&match at
will only works if packages are isolated islands (or at least leaves), but
not in the real world where there are interdependencies everywhere. The more
libraries get modularized and the more alternative versions get offered, the
worse the combinatorial explosion will become. (The number of combinations
grows exponentially with the number of modular dependencies, and linearly
with the number of alternative versions for every single module.)
I guess that in the end, you will have to leave that decision (which
combinations of dependency versions to support) to the maintainer of the
module (in your example, the one that depends on both Python and NodeJS),
which will necessarily leave some users in the cold because their choice of
combination of versions is not supported. But I do not see another option,
also because which depencency versions can be supported also depends on
upstream.
Kevin Kofler