0

I have been asked to "unpack" a binary rpm from a third party, replace a few of the java jar files contained therein, and repackage it so that it installs like the original rpm (for internal use, not redistribution).

I have tried the following:

1) Using alien to convert the rpm to a tgz, un-tarball it, modify it, re-tarball it then convert it from tgz to rpm with alien again

2) Installing the rpm, modifying the jars, then using a tool called rpmrebuild ( http://rpmrebuild.sourceforge.net/ ) to "regenerate" the package.

Both approaches resulted in a litany of error messages and failed.

The docs I have been reading seem to indicate that trying to modify binary rpms may not be a good idea. i.e. " it's not okay to start with pre-compiled code" from ( https://fedoraproject.org/wiki/How_to_create_an_RPM_package#The_basics_of_building_RPM_packages )

Is this an exercise in futility? If not, are there alternate tools / processes I should try?

geoff purdy
  • 35
  • 5

2 Answers2

1

Yes indeed, it sounds problematic to tinker with already built .rpm files, better to rebuild it (maybe even with a slightly different name to clearly distinguish it). Here is what i would do in this rather odd (but in real life certainly possible...) case, assuming we can ignore any licensing related or legal issues here: Unpack the files from the .rpm package, place them into a version control system, and based on this base branch create a separated branch for the rebuilding, where add the custom .jar files, and write a custom .spec file which builds an rpm package from these binary files (with the same dependencies and %pre, %post scripts as the original rpm). With this workflow one can also follow the new releases of the 3rd party "upstream" .rpm package, by checking the new unpacked files into the base branch, and move the needed bits into the other branch, and easy to keep track what has been updated/modified compared to the original package. Also advisable to clarify what is going on with the package in the description of the .rpm package, and set yourself as the maintainer of it. If other packages depending on this package, and also the package name is different from the original package (as i proposed above), one can use the 'provides' and 'conflicts' entries in the new .spec to make sure that the dependent packages' dependencies are fulfilled also by this custom package, and that this custom package won't be installed if the original one is already in the system (or vica versa). For creating .spec file only for installing files, check for example Build RPM to just install files or your favourite rpm tutorial.

Community
  • 1
  • 1
zgyarmati
  • 1,135
  • 8
  • 15
  • If your source comes with a file named like the original package and changing the package name yields errors, add `-n` parameter to `%setup` like so: `%setup -q -n namezipunpacksto`. – DustWolf Mar 03 '21 at 16:34
  • Nice way to celebrate the exact 5th birthday of this question with a follow-up tip ;) – zgyarmati Mar 03 '21 at 18:00
0

An update for anyone reading this. Trying to reverse the .spec file using rpmrebuild then rebuild the package was a cumbersome process.

Ultimately we decided to push the different .jars in a separate process independent of the .rpm. Simpler and easier to maintain.

geoff purdy
  • 35
  • 5