I can't speak on behalf of Neal, but I think I will try to answer.
On Thu, Feb 7, 2019, 10:21 Adam Samalik <asamalik@xxxxxxxxxx wrote:
On Thu, Jan 31, 2019 at 6:19 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: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'm not quite sure I'm following right, but let me try. How are you loosing content?
It moves to different repo where you can't rely on normal behavior of dependency solving between RPMs (unless you have support for modularity in your tooling).
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.
I think the main problem here is that you always say "dnf", "Koji". Other distributions (let's take openSUSE) have their buildsystems and tooling which doesn't use neither dnf or Koji.
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).
But not any other package manager / dependency solver.
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.
Which is Koji-specific and is not integrated in any other buildsystem.
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.
If your module contains some number of build levels (buildorder), then you'd need to wait at least few hours. Did you try to build such modules? (I did)
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.
That would be, for some parts. But you still can't build your own RPM/DNF stack and use new features of this stack to build other packages.
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?
I don't read repodata manually, libsolv does it for me. Using libdnf and/or libmodulemd is not something what (for example) OBS would do. They rely on libsolv for all dependency solving operations. And unless it will support modularity (which depends heavily on DNF people's ability to speak to upstream), nothing will improve.
Unless there is explicit goal to make Fedora incompatible with other distributions, I would like to get all involved people aboard and talk about implementation of modularity in libsolv.
______________________________________________________________________________________________
--
真実はいつも一つ！/ 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
--Software Engineer
Adam Šamalík
---------------------------
Red Hat
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
_______________________________________________ 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
