COPR modular odds

[Cristian Balint]

Dear COPR Team,

Would like to ask a few questions after hitting odds trying to use the
modular features.
My interest is the ability to have mixed stable/nightly releases (user
switchable), so the modularity feature would be ideal.

After looking at several related online resources including copr-framework
source code I decided to ask right here:

#1. Using specific modulemd.yaml, the new module +creates , +builds, +tags
all components picked via repo/ref git path.

$ copr build-module test --yaml dummy.yaml

- But running once again (trying to add updated package) with updated
ref/tags leads to errors:

$ copr build-module test --yaml dummy.yaml
   "Module dummy-master-20220701234448 already exists"

Q: Then how can add *newer* package builds to an existing module ?

Q: Modular builds in the web-frontend expose +extra "Module:" tag, how
can copr-cli launch builds into such a module-tag ?

#2.  Let's assume at #1 modules are created *once* as fixed object and it
is not possible to add/alter with newer package builds:

Q: How can one delete an existing module from COPR (assume it was created
erroneously or obsoleted) ?

Q: How can I avoid having (too) many separate *.repo for each separate
module within a single project ?

Q: Is there a unified way to add only once a *.repo (easy to advertise
URL) and see all the modules within that project ?

Thank you,
~Cristian.

[Jakub Kadlcik]

Hello Cristian,
my apologies for the late reply.

All the questions you ask are valid and understandable. The worst
thing is, that I don't have many positive answers for you.

The modularity support for Copr was implemented in the very early
stage of the Fedora Modularity project itself. IIRC back then it
wasn't known how modules will be updated. Or perhaps it was but we
postponed this with one big TODO. The modularity features in Copr were
revamped and completely rewritten several times since then but the
module updates were never finished, and I am very sorry about that.
> $ copr build-module test --yaml dummy.yaml
> "Module dummy-master-20220701234448 already exists"
> Q: Then how can add *newer* package builds to an existing module ?

Please correct me, but to my understanding, a module is identified as a
name-stream-version. The name-stream part is manually defined but the
version is automatically generated

https://github.com/fedora-modularity/libmodulemd/blob/main/yaml_specs/module...

Therefore, I think two modules shouldn't have the same NSV.

AFAIK we are not supposed to have the "version: ..." defined in the
YAML file, for it to be automatically generated. Then updating a
package in a module should work as simply resubmitting the module
again - it will have the same name-stream but a newer version.

(If anyone can confirm that this is how it is supposed to work, please do so)
> Q: How can one delete an existing module from COPR (assume it was created erroneously
> or obsoleted) ?

Deleting modules was not implemented yet :-/
> Q: How can I avoid having (too) many separate *.repo for each separate module within a
> single project ?
> Q: Is there a unified way to add only once a *.repo (easy to advertise URL) and see
> all the modules within that project ?

I agree with you here, the way to enable modules is awful. There
should be a single modularity repository per project or repository for
each name-stream. And easy `dnf copr` command to enable
it. Unfortunately, it wasn't implemented yet :-/
> Q: Modular builds in the web-frontend expose +extra "Module:" tag, how can copr-cli
> launch builds into such a module-tag ?

I am not sure what "Module:" tag you mean.
> My interest is the ability to have mixed stable/nightly releases (user switchable), so
> the modularity feature would be ideal.

I agree that this would be a good use-case for modularity but I am not
sure that the modularity implementation in Copr is smooth enough for
this. It's up to you. If I could propose a workaround solution, many
other people/teams do this by having two separate projects. One for
nightly builds, one for stable packages. For example

https://copr.fedorainfracloud.org/coprs/g/mock/mock/
https://copr.fedorainfracloud.org/coprs/g/mock/mock-stable/

Jakub

On Sat, Jul 2, 2022 at 11:14 AM Cristian Balint
 wrote:
> Dear COPR Team,
>
> Would like to ask a few questions after hitting odds trying to use the modular features.
> My interest is the ability to have mixed stable/nightly releases (user switchable), so the modularity feature would be ideal.
>
> After looking at several related online resources including copr-framework source code I decided to ask right here:
>
> #1. Using specific modulemd.yaml, the new module +creates , +builds, +tags all components picked via repo/ref git path.
>
> $ copr build-module test --yaml dummy.yaml
> But running once again (trying to add updated package) with updated ref/tags leads to errors:
>
> $ copr build-module test --yaml dummy.yaml
>    "Module dummy-master-20220701234448 already exists"
>
> Q: Then how can add *newer* package builds to an existing module ?
>
> Q: Modular builds in the web-frontend expose +extra "Module:" tag, how can copr-cli launch builds into such a module-tag ?
>
> #2.  Let's assume at #1 modules are created *once* as fixed object and it is not possible to add/alter with newer package builds:
>
> Q: How can one delete an existing module from COPR (assume it was created erroneously or obsoleted) ?
>
> Q: How can I avoid having (too) many separate *.repo for each separate module within a single project ?
>
> Q: Is there a unified way to add only once a *.repo (easy to advertise URL) and see all the modules within that project ?
>
> Thank you,
> ~Cristian.
> _______________________________________________
> copr-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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.fedorahosted.org/archives/list/[e-mail].o...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure