Bug 1585627
| Summary: | Strange change in macro expansions in f29 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | jiri vanek <jvanek> |
| Component: | javapackages-tools | Assignee: | Mikolaj Izdebski <mizdebsk> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | ctubbsii, ignatenko, java-sig-commits, jerboaa, jvanek, mat.booth, mizdebsk, mjw, msimacek, msrb, packaging-team-maint, pmatilai, pmoravco, sgehwolf, sochotni, vmukhame |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | 5.2.0-1 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-06-05 08:58:02 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
jiri vanek
2018-06-04 08:46:32 UTC
Rpm in F28 and F29 is exactly the same, except for dist tag in release. So unless there's a gcc/glibc change causing rpm to misbehave on F29, it's something else. Do you have any suggestion what? I mean what you know from top of head RPM can be calling on its way form spec's scriplet to script and to its execution? So it's %{_jvmdir} that's not getting expanded. Let's see...
It's not defined in the spec, so where is it defined?
[pmatilai@sopuli ~]$ grep _jvmdir /usr/lib/rpm/macros.d/*
/usr/lib/rpm/macros.d/macros.jpackage:%_jvmdir %{_prefix}/lib/jvm
[pmatilai@sopuli ~]$ rpm -qf /usr/lib/rpm/macros.d/macros.jpackage
javapackages-tools-5.0.0-14.fc28.noarch
So there's a build-depdnency on javapackages-tools, but it's not listed as BuildRequires - there's your bug. Comparing the root logs between F28 and F29, something causes it to be pulled into the root on F28 but not so in F29.
Thanx. Then the issue is when we mover *requires* from javapackages-tools to javapackages-filesystem or default buildroot have chnaged. As there was recent clean up of java buildroot, second is more likely. Again, sorry for noise Mikolai, may you confirm? hm. NVM. The buildrequires of javapackages-filesystem will solve it anyway. (In reply to jiri vanek from comment #5) > hm. NVM. The buildrequires of javapackages-filesystem will solve it anyway. This should be BuildRequires: javapackages-tools, right? However, this will then drag in java-1.8.0-openjdk again for a JDK 10 build. Bug 1500288 all over again. So what I'd think would be a better approach is to move the directory macros from /usr/lib/rpm/macros.d/macros.jpackage to javapackages-filesystem. E.g. %_jvmdir %{_prefix}/lib/jvm Macros which use java functions may stay in a separate macro file which then may require java-1.8.0-openjdk. Thoughts? (In reply to Severin Gehwolf from comment #6) > Macros which use java functions may stay in a separate macro file which then > may require java-1.8.0-openjdk. Thoughts? We can do that. Please open an issue at M$ GitHub at https://github.com/fedora-java/javapackages (In reply to Mikolaj Izdebski from comment #7) > (In reply to Severin Gehwolf from comment #6) > > Macros which use java functions may stay in a separate macro file which then > > may require java-1.8.0-openjdk. Thoughts? > > We can do that. Please open an issue at M$ GitHub at > https://github.com/fedora-java/javapackages Here you go: https://github.com/fedora-java/javapackages/issues/57 Severin, Mikolai Thank you. Heaving another jdks in buildroot of jdk itself is not so tragic so I wonted to let it be (until it bites, if ever) Still, heaving the macros in jpt-fs would be much more confortable. TY! Reopening until it is fixed. I believe that this bug is fixed in javapackages-tools-5.2.0-1, which is available in Fedora Rawhide, so I am closing this bug now. The build containing the fix can be found at Koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=1088932 |