rpm2tgz funny or a bug when it comes to directory named 'src'?

dimm0k · 12-28-2012, 10:33 PM

So I'm on Slackware64 14.0 and have been battling with rpm2tgz to run and create AlienBob's dropbox-client from an rpm. Took some time before I broke it down to rpm2tgz not handling the location of the rpm properly. I downloaded the SlackBuild to /usr/custom/src/slackware/dropbox so the resulting path for the script is /usr/custom/src/slackware/dropbox/client. Making no modifications to the dropbox-client.SlackBuild script and executing it caused an issue for me because rpm2tgz was creating a tgz with nautilus-dropbox-1.4.0-1.fedora.x86_64/ as the toplevel directory instead of the usual usr/. After some extensive testing on why this was happening, it boiled down to the rpm being in ANY path that contained a directory named 'src'. As long as that directory name exists somewhere in the path, rpm2tgz bombs. Rename 'src' to anything else and it works fine!

Can anyone confirm?

T3slider · 12-28-2012, 11:09 PM

From /usr/bin/rpm2targz (on Slackware 13.37...may be different in 14.0):

Code:

    if file $i | grep RPM | grep -w src 1> /dev/null 2> /dev/null ; then
      isSource=1
    else
      isSource=0
    fi

`file $i` will output $i in full, so if it contains the path as well (and the path contains src), then it will treat it as a source rpm. To get around this the SlackBuild should make sure to include relative paths (and cd into the appropriate directory before running rpm2tgz to make sure it knows where it is) instead of passing the full filename. Alternatively, rpm2tgz could be patched:

Code:

--- rpm2targz~  2012-12-29 00:07:35.221098034 -0500
+++ rpm2targz   2012-12-29 00:07:46.276867533 -0500
@@ -146,7 +146,7 @@
       isSource=0
     fi
   else # use file.  This works fine on Slackware, and is the default.
-    if file $i | grep RPM | grep -w src 1> /dev/null 2> /dev/null ; then
+    if file -b $i | grep RPM | grep -w src 1> /dev/null 2> /dev/null ; then
       isSource=1
     else
       isSource=0

dimm0k · 12-29-2012, 08:07 AM

Ahh, it's been a while since I've had any interaction with Redhat stuff, but now that you've mentioned it I do remember src referring to source RPMs and can see now why this would be an issue. Thanks for the explanation, as well as the patch to rectify this as it is confirmed working! Any idea if this should be pushed up the Slackware chain for a possible future update? If so, how?