On Thursday, August 24, 2017 3:20:12 AM CEST Kevin Kofler wrote:
> Adam Samalik wrote:
> > all their dependencies, we need to build them. But, for example, a pretty
> > commonly needed thing like autotools [3] has pretty crazy build
> > dependencies [4] including Java, gtk2, gtk3, erlang, X11, python2,
> > python3, etc.
>
> This is exactly why the separate Core and Extras were such a PITA and why
> the Core-Extras Merge was done. Doing the opposite now is a BAD idea.
I have similar feelings, unfortunately.
Dependencies go here and there, new software version means different dependancy
set; that's never-ending iteration in the distro ecosystem. Trying to draw a
thick border line (called "circle") in Fedora Everything to separate the working
ecosystem into smaller ecosystem (where packages in one set don't see the other
sets) is IMO impossible without loosing some part of Fedora functionality (which
is not acceptable as we spent too much power on it so far).
Why I'm writing is the mentioned "autotools" keyword (for some reason it is
privileged soon-to-be module, dunno why). We should first define "what belongs
to autotools". But anyways... Making it a self-standing module is not easily
possible. All the (build)deps are there for reason. We really don't want to
have "language foo" support in Automake without having that tested during
build-time (since that's the only testsuite the upstream can maintain). It
means that build (and probably runtime) of Automake will depend on "lang foo"
forever (and that's noarch, with library deps it is even worse). Why we are
making problems from non-problem [4]?
Ok, I agree that Fedora needs modules for life-cycle separation. But I don't
understand why we start "bottom up" and not the other way around. Why we we
start with the base build toolset like autotools, instead of with leaf
packages on which (almost) nobody depends on? Good examples are
{ RHSCL } / { languages } ... Subtract language-collections as modularity
doesn't solve "parallel install-ability" so multiple versions of Python
versions won't be possible in module world (rhscl allows that).
Pavel
> Modularity may sound great on paper, but as soon as you actually try to
> implement it, it falls apart like a house of cards.
>
> Kevin Kofler
Adam wrote:
> >[4] https://github.com/fedora-modularity/dependency-report/blob/original-plan/modules/autotools/all/buildtime-binary-packages-short.txt
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
