V Fri, Sep 10, 2021 at 08:50:44AM -0400, Neal Gompa napsal(a): > On Fri, Sep 10, 2021 at 8:26 AM Petr Pisar <ppisar@xxxxxxxxxx> wrote: > > > > Good news, module maintainers. > > > > I'm relieved to announce an availability of the new module packaging format, > > modulemd-packager, version 3. > > > > So this certainly solves a lot of issues, but it's still frustrating > to see that we *need* to declare the platform and that we couldn't > inherit the platform from the build environment. This means that at > branching time, we need to make a commit to change the requested > platform. > I confirm it is so and I fully agree with you that it's unpleasant. The problem is that if you want to have the context invariant, then you need to store a mapping between a context and its build-dependencies somewhere. And naturally as new Fedora releases are added, and end-of-live releases removed, the mapping must be updated because platform is one of the dependencies. > That being said, does the platform value influence how the final > modulemd is generated? That is, if I made a system that accepted this > YAML file as input but *ignored* the platform value It would end up like this <https://pagure.io/fm-orchestrator/issue/1714>: The build service would mix contexts for different platforms and the module wouldn't probably build at all like in the referred issue. > (and the platform was forced by other means) For example? The information has to be somewhere stored, somehow retrieved, and delivered to a build and compose systems. In non-modular world the information is stored in dist-git branch name, delivered to Koji as a build target, and stored in Koji build as tag. The information is updated with each Fedora release. The process of updating is called branching and package retirement. I was thinking about possible solutions: One was omitting platform from the context. You would not specify any platform in the module input format. - context: A You would submit the module for building. MBS would expand the build for all platforms (= currently supported Fedoras). The result would be four module builds: Build Dependencies ------------------------------------------- perl:5.32:362021:A platform:36:0:0 perl:5.32:352021:A platform:35:0:0 perl:5.32:342021:A platform:34:0:0 perl:5.32:332021:A platform:33:0:0 But somewhere would have to be stored for which platform was the build done. We can guess it from the version prefix (36..., 35...) now. (ELN has no prefix.) Then when you build perl-DBI:1.643 which build- and run-requires perl:5.32: - context: A buildrequires: perl: [5.32] requires: perl: [5.32] the same way without platforms, MBS would expand a matrix of the platforms and perls: perl-DBI:1.643:362022:A platform:36:0:0 perl:5.32:362021:A perl-DBI:1.643:352022:A platform:35:0:0 perl:5.32:352021:A perl-DBI:1.643:342022:A platform:34:0:0 perl:5.32:342021:A perl-DBI:1.643:332022:A platform:33:0:0 perl:5.32:332021:A That would work. But how would a packager specify that he does not want to build for all plaforms? E.g. he adds a module to Fedora 36 and is not interested in the older ones. Or e.g. he stops maintaining the module and the last supported is Fedora 35. Maybe we could add a new field into the input file: - platforms: [f33, f34, f35] - context: A buildrequires: perl: [5.32] requires: perl: [5.32] and default to all platforms if not specified. When I shared this idea I was told that a context must change with a platform. That everything (MBS?) assumes it. I believe I was also told another, reasonable reason. But I cannot recall now. I'm sorry I cannot provide better explanation now. However, it's true that it does matter much whether the platform is encoded into the version or into the context (perl:5.32:362021:A vs. perl:5.32:2021:36A). If we hadn't it encoded anywhere, we could not store the builds into Koji, and MBS: perl:5.32:2021:A platform:36:0:0 perl:5.32:2021:A platform:35:0:0 perl:5.32:2021:A platform:34:0:0 perl:5.32:2021:A platform:33:0:0 And it's true that we would only special-case platform. It wouldn't be fair to other modules. There must a stroger reason. -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
