Bug 204660
| Summary: | jpackage-utils looks for files in wrong locations (/usr/bin/rebuild-security-providers) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> | ||||||||||
| Component: | jpackage-utils | Assignee: | Thomas Fitzsimmons <fitzsim> | ||||||||||
| Status: | CLOSED RAWHIDE | QA Contact: | |||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | medium | ||||||||||||
| Version: | rawhide | Keywords: | Reopened | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2006-09-02 21:30:31 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
Yes, the location of classpath.security just changed in libgcj and I hadn't updated jpackage-utils to match yet. Fixed in jpackage-utils-1.6.6-1jpp.7 in Rawhide. Created attachment 135337 [details]
fix for rebuild-security-providers script
Unfortunately whatever was done with this script does not work.
Maybe because the package is 'noarch', which I missed, and is rebuild
in a "wrong" context.
Attached patch is one way of fixing this issue. It takes also
an opportunity to remove a "dead cat".
Created attachment 135385 [details]
updated fix for rebuild-security-providers script
Yes, I forgot that %{_libdir} is randomly defined in noarch packages.
Can you try the attached script? It should also work in the case where
libgcj.i386 and libgcj.x86_64 are installed in parallel.
The script attached to comment #3 will work but it has one catch. In case when some of directories in question exist, but without a coresponding classpath.security file in those, such file will be created and only with "security.provider" lines. I am not so sure if this is an effect you are after. Maybe instead of touch "$secfile" line the following [ -e "$secfile" ] || continue should be used instead? Or even more specific '-f' instead of '-e'? Oh, in a case you will use an existence test you do not even have to bother with testing for a presence of directories. You can simply make $secfiles list of all possible candidates, something like this: secfiles=" /usr/lib/security/classpath.security /usr/lib64/security/classpath.security " and loop through it skipping those which do not exist. Created attachment 135396 [details]
another update
Can you try this version?
Created attachment 135407 [details] yet another variant > Can you try this version? Yes, as long as your $secfiles list is complete this clearly works. But how "race sensitive" it is? We can avoid going through .bak file. I also do not grok why sort is used. An output of ls will be already sorted. So how about a version attached here? We used the .bak notation because older versions of sed did not support -i, and awk to be sh-compatible. But seeing as we have bash and the new version of sed in Fedora, I think your changes are fine, so long as we make it a #!/bin/bash script and explicitly require /bin/bash. The script is race sensitive, but I only expect it to be used by rpm, which serializes package installations. Can you please try jpackage-utils-1.6.6-1jpp.8, which I just built into Rawhide, and close this report if it fixes the bug? |
Description of problem: A script /usr/bin/rebuild-security-providers "hardwires" location /usr/lib/security/classpath.security instead of using /usr/%{_lib}/... expanded in a build time. As a result an attempt to use it ends up with a number "No such file or directory" just because they are really not there. Package scripts of java-1.4.2-gcj-compat call the script in question with easy to predict effects. Version-Release number of selected component (if applicable): jpackage-utils-1.6.6-1jpp.6