Bug 204660 - jpackage-utils looks for files in wrong locations (/usr/bin/rebuild-security-providers)
jpackage-utils looks for files in wrong locations (/usr/bin/rebuild-security-...
Product: Fedora
Classification: Fedora
Component: jpackage-utils (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Fitzsimmons
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-08-30 13:40 EDT by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-02 17:30:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
fix for rebuild-security-providers script (1.09 KB, patch)
2006-08-31 17:29 EDT, Michal Jaegermann
no flags Details | Diff
updated fix for rebuild-security-providers script (750 bytes, application/octet-stream)
2006-09-01 11:36 EDT, Thomas Fitzsimmons
no flags Details
another update (603 bytes, application/octet-stream)
2006-09-01 13:21 EDT, Thomas Fitzsimmons
no flags Details
yet another variant (497 bytes, application/octet-stream)
2006-09-01 15:03 EDT, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2006-08-30 13:40:41 EDT
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):
Comment 1 Thomas Fitzsimmons 2006-08-30 13:51:45 EDT
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.
Comment 2 Michal Jaegermann 2006-08-31 17:29:21 EDT
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".
Comment 3 Thomas Fitzsimmons 2006-09-01 11:36:17 EDT
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.
Comment 4 Michal Jaegermann 2006-09-01 12:00:09 EDT
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'?
Comment 5 Michal Jaegermann 2006-09-01 12:09:26 EDT
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:


and loop through it skipping those which do not exist.
Comment 6 Thomas Fitzsimmons 2006-09-01 13:21:20 EDT
Created attachment 135396 [details]
another update

Can you try this version?
Comment 7 Michal Jaegermann 2006-09-01 15:03:47 EDT
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?
Comment 8 Thomas Fitzsimmons 2006-09-01 16:08:12 EDT
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?

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