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/mod...
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
<cristian.balint(a)gmail.com> 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 -- copr-devel(a)lists.fedorahosted.org
To unsubscribe send an email to copr-devel-leave(a)lists.fedorahosted.org
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/copr-devel@lists.fedorahoste...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure