On 2019-04-26, Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > On 26. 04. 19 10:55, Vít Ondruch wrote: >> How does modularity make it easier though? >>> >>> It seems to me that it does the exact opposite - instead of having >>> one version of each package to maintain I now have multiple versions >>> to worry about! I mean obviously I could convert to a module and >>> only maintain one version but what would be the point? >> >> Converting to module does not mean maintaining one version. It means >> that you have to maintain the one version on multiple versions of >> Fedora, where previously this was not needed. >> >> E.g. if there is new OpenSSL in Rawhide and Ruby needs to be modified >> somehow, then the modification has to be compatible with older Fedoras, >> whereas previously you would do that change just for Rawhide. >> >> TBH, keeping modules alive is much harder then it was without modules. >> Not even mentioning the possibility of having multiple versions ... > > And yet somehow, somebody considers that easier. > I still try to understand that and I always fail. > Modularity was designed to have a module life cycle independent from the underlying distribution. I.e. having one stream built from one sources for multiple Fedoras. This is a benefit for users. (If we assume that users care what version of software they use. We could maybe consider users as developers in this matter.) Having the same sources on multiple Fedoras of course implies a packager has to maintain compatibility across multiple Fedoras. In the end it's exactly what an upstream struggles for. If you are an upstream then you want to enable your users to build the same code for multiple distributions. It makes packagers to produce more upstreamable patches. Is it more labour for packagers? Yes, it is. But it frees the packager from worrying Did I apply the fix for all supported Fedoras? Do I have to resolve merge conflicts when backporting patches? I believe this is what Mikołaj found attractive and why decided for modules. This is especially true for closed ecosystems like Java packages that have almost no dependencies on non-Java stuff. In this perspective modularity can be beneficial for packagers too. Controversial property of modules are private build-time dependencies. Modularity allows packagers to hide them and to not to support them (to the extend that they work in my module). However, this privatisation has costs. It means duplication of work unless two packager realize they can refer to the same package from their modules. But the common package is whose responsibility now? And looking back at users, poor users won't get that package for free. Yes, I agree that that this aspect of modularity hinders an integration role of packaging. Integrating thousounds of pieces of software, all of them as first-class citizens and offering them to users makes distributions very attractive for developers or anyone who wants to fork or spin of flavour or extend the distribution. One can dispute that now nobody, especially developers, needs distributions with a wide selection of software because everybody uses containers and installs software from upstream bypassing distributor's packages. Well, that may be true for closed ecosystems (like Java maven artifacts, Ruby gems etc.), however, look at any CI configuration files (those foo.yml poluting roots for git repositories). They start with "dnf install openssl-devel"-like incantation. Distributions are not dead. They are still needed. And will be needed untill those fancy upstream ecosystems (CPAN, PyPI etc.) gets to know how integrate with foreign pieces (e.g. with C libraries). In my humble opinion modularity would be more beneficial if every RPM package gets it's own that-package-contained module by default. This plethora of modules would of course demand appropriate tooling. Tooling as we have around RPM (repositories, composes, package managers). Or vice versa instead of reinventig weel enable Koji to expand-build one SRPM for multiple Fedoras. And enable composes to contain multiple version of packages. And having the build-only packages/modules in a separate "unsupported" repository or just flagged in metadata as unsupported. The issue with modules in Fedora is that they look like aliens (metadata and tooling), behave like aliens (dnf system-upgrade) and are born like aliens (MBS above Koji). -- Petr _______________________________________________ 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
