...
I still don't understand what Frankenstein buildroot we are using.
2 lines in a mock file allow to be aware of modules...
modules=1
...
config_opts['module_enable'] = ['php:7.4', ...
2h of work to find the proper configuration and
I was able to build such packages since the day RHEL-8-Beta
was made publicly available, in May 2018... 3 years ago
and still waiting for something to happen in EPEL
Maybe allow some spec switch to do that? But it is noobs suggestion based on not-knwoing.
It is easy to do this in a mock. It isn't easy to do this in koji and
or mbs because they assume they 'built' everything they are going to
use to build other things. This means we either have to build all of
RHEL with the Fedora koji/mbs packages so they 'understand' what is
there.. or you have to come up with some sort of hack which does
something like this:
1. koji/mbs create the mock.cfg file and start setting up a buildroot
on a builder.
2. your script rewrites the mock.cfg with the config items and fake
koji/mbs into everything is ok.
3. koji/mbs continues the build
The problems with this method are the following:
1. You have to hand edit the script to know what modules are being
used and for when.
2. You have to hope that 2 doesn't get abused in multiple ways
3. It is kludgy and breaks a lot so you end up doing a 'repeat build
until either fail_counter=X || build_complete'
4. You end up needing to do this separately from the regular Fedora
koji/mbs because if you can do this in one build root, you can do it
in all..
The way EPEL is set up is a third way which is a 'best of worst worlds' method:
1. You download RHEL packages into a repository
2. You run a demodularizer which breaks apart the modules into a one
tree. You have to be careful because some modules conflict so you only
do the ones which are 'Default' or in CodeReady
If I take look to my error:
Problem 1: conflicting requests
- package maven-compiler-plugin-3.7.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering
Problem 2: conflicting requests
- package maven-jar-plugin-3.1.0-1.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering
Problem 3: conflicting requests
- package maven-local-5.3.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering
Then from thsi demodualrize-explaining sentence I would guess, that I'm useing jsut wrong versions . I already tried to play with various BuildRequires xyz > or < a.b but mostly did it just worse.
In addition, I had failed to search koji/centos builder for this dependence checks and was moreover blindly shooting.
thoughts?
Thanx a lot for all the inputs!
3. You rebuild this into a single repository
4. koji looks at this as an external repository like it has done from
EPEL-5 days. This uses a method which was meant for just kickstarting
a build tree by having an external tree to point to but works for
RHEL. Koji tries to deal with this but it causes issues
5. mbs still only knows how to use modules it built itself.. This
means that the external modules in RHEL are invisible to it. This is
what breaks it from being able to build PHP modules.
In the end, the core problem is that we are (ab)using the koji/mbs
build structure to do things it was never intended to do. It has been
made to do it, but deep down it is like making pizza on a shovel at a
blacksmith.. you can do it but neither the forge or the shovel were
meant for this and you end up constantly trying to figure out how to
remove coal tar from the food.
Ex:
https://rpms.remirepo.net/temp/epel-temp.repo
And mock configuration
https://git.remirepo.net/cgit/tools/mock.git/tree/epel874.cfg
Remi
_______________________________________________
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
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
_______________________________________________
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
