On Thu, Jan 31, 2019 at 6:07 AM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Jan 29, 2019 at 11:06:25PM -0500, Neal Gompa wrote:
> > Please don't do that. You'll basically break the distribution for all
> > third-party packagers. Modules are not supported by anyone at all, and
> > it's too difficult to integrate as it currently stands (and I'm
> > actually trying because of the impending doom that is RHEL 8).
>
> Can you elaborate? How would this break third-party packagers?
>
I've mentioned this before in other places, but the Fedora Modularity initiative, as currently designed and implemented, is functionally impossible for me as a third-party packager to use. As stuff moves from the regular repository to the modular repo, I lose access to that content for dependencies. This affects my ability to ship software for Fedora as part of the work I do for my day job. And once the distribution starts requiring modules to function or to access entire ecosystems (like Java), I'm SOL.
I was horrified when I found out that RHEL 8 was "modularized" in this manner, because I can't construct a build environment for it right now. There was no thought into the broader ecosystem, or even solving the problem in a reasonably compatible manner.
A lot of my tools just flat out break because the assumption that rpm-md is always XML was broken by modulemd for repodata being YAML instead of XML. My ability to hack together even a jerry-rigged solution has been hampered by the fact that I can't even access all the different options easily either. The repository looks like nonsense and everything is basically broken to conventional tools because of the massive collection of conflicting sets of packages with odd NVRs that make version comparisons behave oddly.
--
真実はいつも一つ！/ Always, there's only one truth!
>
> On Tue, Jan 29, 2019 at 11:06:25PM -0500, Neal Gompa wrote:
> > Please don't do that. You'll basically break the distribution for all
> > third-party packagers. Modules are not supported by anyone at all, and
> > it's too difficult to integrate as it currently stands (and I'm
> > actually trying because of the impending doom that is RHEL 8).
>
> Can you elaborate? How would this break third-party packagers?
>
I've mentioned this before in other places, but the Fedora Modularity initiative, as currently designed and implemented, is functionally impossible for me as a third-party packager to use. As stuff moves from the regular repository to the modular repo, I lose access to that content for dependencies. This affects my ability to ship software for Fedora as part of the work I do for my day job. And once the distribution starts requiring modules to function or to access entire ecosystems (like Java), I'm SOL.
I was horrified when I found out that RHEL 8 was "modularized" in this manner, because I can't construct a build environment for it right now. There was no thought into the broader ecosystem, or even solving the problem in a reasonably compatible manner.
A lot of my tools just flat out break because the assumption that rpm-md is always XML was broken by modulemd for repodata being YAML instead of XML. My ability to hack together even a jerry-rigged solution has been hampered by the fact that I can't even access all the different options easily either. The repository looks like nonsense and everything is basically broken to conventional tools because of the massive collection of conflicting sets of packages with odd NVRs that make version comparisons behave oddly.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
