On Thu, 24 Oct 2019 at 06:55, Kevin Kofler <kevin.kof...@chello.at> wrote:
>
> 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.
>
I am in agreement with Kevin on this. I find that the self-hosting
expectation (the hood of the car is not welded shut) is what makes me
interested in working on Linux distributions. That said, I also
understand one reason why there are buildroot-only packages: lots of
software needs 'extra' things and there are not enough packagers to
cover all of them at the same level as leaf and some core packages.
(Hypothetical) If I need libfoo to build libreoffice and I don't want
to support/trackdown bugs on libfoo then I either drop libreoffice,
make a half-ass job on libfoo, or try to do both and burn out because
libreoffice is going to take 150% of my time anyway. Being able to put
a libfoo in a 'yeah its there but if you open bugs on it .. no one is
going to really fix them unless they affect my package libreoffice' is
very appealing.
> > * 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.)
Again agreed. Mathematically this is going to grow immensely because
each packager is going to do their own thing ot get the job done and
you are going to end up with 100 minidistributions with a larger
bureaucracy than we have currently to make sure things aren't stepping
on each others toes all the time.
> 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
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Stephen J Smoogen.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
