On Thu, Jan 31, 2019 at 6:19 PM Neal Gompa <ngompa13@gmail.com> wrote:
On Thu, Jan 31, 2019 at 6:07 AM Matthew Miller <mattdm@fedoraproject.org> 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'm not quite sure I'm following right, but let me try. How are you loosing content?

During runtime, DNF picks up content (meaning RPM packages) regardless them being in a default module or standalone. For example, "dnf install dwm" works the same way on f28 where dwm is a standalone package, and f29 where dwm is in a default module.

During build, it's a bit more complex because you can build standalone packages or modules, and you can do local builds or builds in the Fedora infra — that's four different scenarios in total:

1) Local builds of standalone packages — just adding the modular repo into your mock config makes DNF to pick up packages for the buildroot the same way as described above, it doesn't really matter if they are in a default module or standalone. This is, however, not enabled by default to be consistent with 2).

2) Fedora infra builds of standalone packages — modular content is currently invisible to standalone package builds. That said, the Modularity Team is actively working on making that possible. You might have heard about "Ursa Major" which is a funny name for a solution that injects default module streams into the traditional buildroot. Alternatives have been also discussed in the past few weeks. But please understand this the reason it doesn't work at this moment is not the design, but rather the work still being in progress. And before that's done, we do not allow packages used as build dependencies to be completely moved to a default module before we fix this — so nothing should break for you.

3) Local module builds — I'll just point you to the docs [1] here. Although the current experience is not ideal, it's functional and remains on the Modularity Team's list of things to tackle. We'd appreciate your input if you're interested in building modules locally.

4) Fedora infra builds of modules — I'll point you to the docs [2] again. There should be no issues with module builds in the infra.

So... I'm not sure how are you loosing content right now, you shouldn't be. Do you have an example?

 

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.

Did you hear about the CodeReady Linux Builder [3] repository? 

Regarding the broader ecosystem and the amount of thoughts that went to it, and I'm just speculating now, if Modularity ever gets to EPEL, wouldn't modules actually make it easier to build content for RHEL 8? You could in theory even build alternative versions of packages that replace RHEL content thanks to non-default modules. I feel like that would be a huge benefit.



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.

All right, "looks like nonsense" and "everything is basically broken" mean nothing specific to me, and it's hard to help you here even when I really want to. But it sounds like you're reading the repodata manually — wouldn't using DNF / libdnf / libmodulemd help? Or are you writing your own tools?
 


--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org


--

Adam Šamalík
---------------------------
Software Engineer
Red Hat