Bug 2104257 - adapt crypto-policies to removal of java on i686
Summary: adapt crypto-policies to removal of java on i686
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: crypto-policies
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Red Hat Crypto Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 2083750 2104259
TreeView+ depends on / blocked
 
Reported: 2022-07-05 19:25 UTC by jiri vanek
Modified: 2023-09-15 01:56 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2022-07-18 17:13:47 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FC-495 0 None None None 2022-07-05 19:27:58 UTC

Description jiri vanek 2022-07-05 19:25:04 UTC
Dear maintainer, we are going to drop i686 java-openjdk packages in f37 - https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
Your package (maybe jsut some subpakcage) is transitively affected by this change:

openssl-devel<-openssl-libs<-crypto-policies<-java-1.8.0-openjdk-devel
openssl-devel<-openssl-devel<-openssl-libs<-crypto-policies<-java-1.8.0-openjdk-devel
openssl-devel<-openssl-devel<-openssl-devel<-openssl-libs<-crypto-policies<-java-1.8.0-openjdk-devel
openssl-devel<-openssl1.1-devel<-openssl-devel<-openssl-libs<-crypto-policies<-java-1.8.0-openjdk-devel
openssl-libs<-glibc<-gawk<-git<-subversion<-java-11-openjdk-devel
openssl-libs<-glibc<-gettext<-git<-subversion<-java-11-openjdk-devel
openssl-libs<-glibc<-procps-ng<-git<-subversion<-java-11-openjdk-devel


This package was selected as one of the most crucial, which when missing, will burn distro down.
Please take care, and adapt  your package to exclude java on i686. For your convenience, there was added macro %{java_arches}, including all arches java is available on,  which you can use to ifarch-out java specific features out in i686 (on non-java arches). Although for plain java package, the change is as simple as https://src.fedoraproject.org/rpms/maven/c/520942645bfd1e4721dacd536a6ccbf80495a8ae?branch=rawhide, you can not use it. The ExclusiveArch: %{java_arches} is not going to work for you, because your package is not simple java application, and also non-java world depends on it (even if you are one of dozen noarchs in this set)
See exemplar PR: https://src.fedoraproject.org/rpms/graphviz/pull-request/9#request_diff
See more details eg in:: https://bugzilla.redhat.com/show_bug.cgi?id=2102298
See why in : https://pagure.io/fesco/issue/2772
Please read carefully proposal: https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
Please see tracking bug for most up to date informations: https://bugzilla.redhat.com/show_bug.cgi?id=2083750
(note, that direct dependencies are already work in progress - native reported and worked on, noarch ones autoadjusted)

I'm terribly sorry to report this bug so late in f37 lifecycle. If you can, please handle this with priority.

Comment 1 Clemens Lang 2022-07-06 10:36:43 UTC
As discussed in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/LZY7R6BBQG3XQG6RVCYG2WNWPCGMOFY4/, this is a problem for the subversion or git packages to fix, not for openssl.

However, crypto-policies' dependency on java should be investigated. Unfortunately it seems no ticket was filed for crypto-policies for this change. I'll re-name and re-assign this ticket to track this.

Comment 2 Clemens Lang 2022-07-07 10:31:55 UTC
crypto-policies is noarch, so is this even a problem?

Comment 3 Tomáš Mráz 2022-07-07 10:33:09 UTC
crypto-policies requires java only for build to be able to run tests of the java crypto policy. The build arch of crypto-policies is noarch. I do not know if it is possible to somehow exclude build on i686 for a noarch build.

Comment 4 Alexander Sosedkin 2022-07-18 17:13:47 UTC
It's not and I'm just gonna close the bug.

Comment 5 jiri vanek 2022-07-19 15:12:21 UTC
Hello!

This may get more tricky, and my advice is to reopen the bug.
Crypto policies, as being noarch, and direclty depending on java, has ben amended by me, instead havinf filled the bug. 
I have 2weeks ago i injected https://src.fedoraproject.org/rpms/crypto-policies/c/675ff515727bbe0188b5f0dbd8fdc7dbefc5b470?branch=rawhide ;  which is actually doing what Tomas wanted (so Alexandr is wrong), however, that "solution" have bug in bbug.  By design, such pkg should will not be availabl in i686 repos. (if pkg have exclusive arches, it builds only on them, but even if noarch, it is available only there). But luckily there is bug.. in pungi... which is invalidating the desig. In all cases, the behavior is not reliable. In adition, we no longer have i686 repos, they are multilib only... So the i686 will inherit all x86_64's noarch pkgs....

If the java deps i s only for tests, I recomed to revert my "fix" and ifarch onky the test and java dependence. Of course you can keep it as it is, and take a risk (whihc should be safe by all my thinking, but others thinks differently)

Comment 6 Andrew John Hughes 2022-07-19 17:18:08 UTC
(In reply to Tomáš Mráz from comment #3)
> crypto-policies requires java only for build to be able to run tests of the
> java crypto policy. The build arch of crypto-policies is noarch. I do not
> know if it is possible to somehow exclude build on i686 for a noarch build.

Could we not migrate these to the JDK?

We are also running tests to make sure the JDK is using crypto policies, which means we have a build requirement on crypto-policies... So removing the dependency from crypto-policies would not only fix the i686 issue on Fedora, but also fix a cyclic dependency.

Comment 7 Alexander Sosedkin 2022-07-19 17:25:22 UTC
> revert my "fix" and ifarch onky the test and java dependence

could you elaborate what do you mean by that? somehow conditionalizing the BuildRequires on java?

Comment 8 Red Hat Bugzilla 2023-09-15 01:56:38 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days


Note You need to log in before you can comment on or make changes to this bug.