Bug 1600426
| Summary: | Reconsider auto-requires: javapackages-tools | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Severin Gehwolf <sgehwolf> |
| 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, java-sig-commits, mizdebsk, msrb, sgehwolf, sochotni |
| Target Milestone: | --- | Keywords: | FutureFeature, Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | javapackages-tools-5.2.0-6.fc29 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-04-09 18:47:12 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
Severin Gehwolf
2018-07-12 08:29:38 UTC
(In reply to Severin Gehwolf from comment #0) > What is the reason for auto-requires of javapackages-tools? If it's the > directory structure this should get switched to javapackages-filesystem > instead which won't have a dep on the JDK. The reason is that this requirement is mandated by Java packaging guidelines [1]. I'm not going to change generator unless guidelines are updated first. The process to change guidelines is described at [2]. [1] https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires [2] https://fedoraproject.org/wiki/Packaging_Committee#Guideline_Change_Procedure (In reply to Mikolaj Izdebski from comment #1) > (In reply to Severin Gehwolf from comment #0) > > What is the reason for auto-requires of javapackages-tools? If it's the > > directory structure this should get switched to javapackages-filesystem > > instead which won't have a dep on the JDK. > > The reason is that this requirement is mandated by Java packaging guidelines > [1]. [...] > [1] https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires That doesn't really answer the question why it's there in the first place. There must have been a reason as to why a runtime requirement on javapackages-tools is needed. I'd have thought a requirement on some java-headless >= X to be sufficient plus dir-ownership, which javapackages-filesystem would do. Would you happen to remember why it was added? If we know that it gives us better grounds to change the guidelines (if needed). Thanks! https://pagure.io/packaging-committee/issue/260#comment-145632 seems to suggest it's for dir ownership. Why it's in the guidelines would be question for packaging list or FPC, not javapackages-tools maintainers. But I can try to answer it best I can. From what I know JPackage project had jpackage-utils, which was a single package containing various Java-related utilities. It also owned Java-related directories. There was practice (not documented in "JPackage Policy") for all packages to require jpackage-utils. For directory ownership, and more - packages could import shell functions from JPackage library, run utility scripts to locate JVM, find extension JARs and so on. Fedora Java packaging was inherited from JPackage. Java Packaging guidelines was based on JPackage policy and practices. Over time it was simplified to better match rest of the distribution, diverging from JPackage. At some point auto-requires generators were implemented and we started generating requires on jpackage-utils so that explicit Requires wouldn't have to be listed in spec files by packagers manually. Later a single FPC member decided to change guidelines and replace jpackage-utils with javapackages-tools - without FPC vote, without contacting Java SIG or javapakcages-tools maintainers. I didn't see this change announced either. A few months later, when I noticed it, I updated javapackages to follow guidelines. When javapackages-filesystem was introduced I didn't switch generators to it because I would either need to violate packaging guidelines, or engage with FPC to change it, for which I don't have time and energy. I consider this bug closed, you can reopen it once guidelines is changed and I will obey FPC decision. (In reply to Mikolaj Izdebski from comment #4) > Later a single FPC member decided to change guidelines and replace > jpackage-utils with javapackages-tools - without FPC vote, without > contacting Java SIG or javapakcages-tools maintainers. I didn't see this > change announced either. A few months later, when I noticed it, I updated > javapackages to follow guidelines. > Decision wasn't made in a vacuum, someone asked the committee to change the guidelines: https://pagure.io/packaging-committee/issue/521 Looks like Tibbs thought he was updating guidelines to reflect what was actually happening in real life (factual corrections and typos are not normally put to the vote.) (In reply to Mikolaj Izdebski from comment #1) > (In reply to Severin Gehwolf from comment #0) > > What is the reason for auto-requires of javapackages-tools? If it's the > > directory structure this should get switched to javapackages-filesystem > > instead which won't have a dep on the JDK. > > The reason is that this requirement is mandated by Java packaging guidelines > [1]. I'm not going to change generator unless guidelines are updated first. Java packaging guidelines have been updated: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/HP4LRC2RJNMOMXITZZYJ6FLF2RITY6H6/ Severin, IIRC you had a list of packages that were importing shell functions. Could you add explicit requires on javapackages-tools to them before generators are updated? (In reply to Mikolaj Izdebski from comment #8) > Severin, IIRC you had a list of packages that were importing shell > functions. Yes. See: https://lists.fedoraproject.org/archives/list/java-devel@lists.fedoraproject.org/message/WVZOI7I27SAOUVF2SGCRLGVPEFFHXGWP/ > Could you add explicit requires on javapackages-tools to them > before generators are updated? Sure, I'll put that on the TODO. I'll add that no later than F30 branch point. Are we still going with a system wide change for this? Adding need-info on myself so I won't forget. (In reply to Severin Gehwolf from comment #9) > Are we still going with a system wide change for this? The main purpose of the change process is to open discussion and gather feedback about the change. But since the decision to implement this change has already been made (by FPC which has FESCo mandate for these stuff), the change process would be pointless at this point. Generators were updated in rawhide. Upstream change: https://github.com/fedora-java/javapackages/pull/63 (In reply to Severin Gehwolf from comment #9) > (In reply to Mikolaj Izdebski from comment #8) > > Severin, IIRC you had a list of packages that were importing shell > > functions. > > Yes. See: > https://lists.fedoraproject.org/archives/list/java-devel@lists.fedoraproject. > org/message/WVZOI7I27SAOUVF2SGCRLGVPEFFHXGWP/ > > > Could you add explicit requires on javapackages-tools to them > > before generators are updated? > > Sure, I'll put that on the TODO. I'll add that no later than F30 branch > point. Are we still going with a system wide change for this? I've had a look at these 82 SRPMs as determined by earlier analysis. Some of them have explicit requirements on jpackage-utils, provided by javapackages-tools, so were a no-op. For the ones for which I've determined that they now need javapackages-tools I've added the requirement and have rebuilt them. The list was: 389-console accumulo antlr antlr3 antlr4 antlrworks apache-rat aqute-bnd batik bolzplatz2006 bsh bundling-detection-java CardManager checkstyle clapham closure-compiler console-image-viewer derby ditaa eclipse fop freecol freerouting gherkin2-java gogui gradle HdrHistogram itext jarjar javacc java-deptools javadocofflinesearch javahelp2 java-wakeonlan jdiff jenkins jetty jflex jing-trang jmol josm jpanoramamaker jsonld-java-tools jtidy junit5 legendsbrowser liquibase log4j logisim Mars maven metadata-extractor2 modello msv mvel nekohtml neurord objectweb-asm3 objectweb-asm ohc OpenStego plantuml portecle proguard rachota rhino scala shiro sunflow svnkit tika tomcat tonto weka will-crash woden xerces-j2 xjparse xml-commons-resolver xmvn yuicompressor zanata-platform I believe we can close this bug with resolution RAWHIDE. |