rpmlint
is a tool to check RPMs against some sort of packaging policy. Its configuration is typically distribution dependant and it checks packages against the particular distribution policy. Checking your own packages is fine as long as this is what you want.
If your policy differs from the distribution policy, you either have to configure rpmlint
accordingly, refrain from using it or ignore the specific errors.
The following should do the trick when added to /etc/rpmlint/config
or ~/.config/rpmlint
(not tested):
addFilter("E: dir-or-file-in-usr-local")
Sources:
It's possible but highly difficult to do this so that it's done correctly. If you're desperate you can create a new RPM .spec
file and construct a "fake" source RPM (SRPM) file which you can then use to construct a resulting RPM file using rpmbuild --rebuild
.
I would continue searching for the actual RPM instead. You don't state which in your question but it's been my experience that you can find anything on the internet if you know how to search for it. I've found ancient versions of RPMs for Red Hat distros that haven't been in use for 10+ years so I'd find it hard to believe that there is no remnant of this RPM anywhere.
Also you can often times go back to the source of the application that's contained within the RPM and use that to reconstruct the RPM too. Often times the source apps will include a necessary .spec
file which is used to rebuild the RPM.
Lastly you could get the source and the .spec
file from a build service such as Koji for Red Hat based distros. SuSE maintains similar build services as well so you can search through these to get old build artifacts.
Taking the binaries as are
You can use this method to lift the actual executables from one system and tar them up for deployment on another system.
machine A
$ rpm -ql <packageNameHere> | xargs tar -zcvf /tmp/program.tgz
machine B
$ tar -zxvf /path/to/your/program.tgz
SLES's version of RPM
According to one of the posts in this thread: Re: How to create RPM fron installed packages rpm
on SLES is purported to have the switch --repackage
. This doesn't exist on the Red Hat version (in Fedora or CentOS). But according to the post you can use it like so:
$ rpm -e --repackage <somepackage>
After that completes you'll find your RPM accessible here:
/var/spool/repackage
Using rpmerizor
Rpmerizor is a 3rd party tool/script that you can install which will re-package source files into a corresponding RPM. The usage of this script is accessible here, titled: rpmerizor's man page.
excerpt
Rpmerizor is a script that allows you to create an RPM package from installed files. You simply have to specify files on the command line and answering a few interactive questions to fill rpm meta-data (package name, version ...). You can also use it in batch mode with command line options for meta-data.
Using rpmrebuild
Not to be confused with the build tool rpmbuild
, rpmrebuild
is another 3rd party script you can use to do a re-packaging of an already installed RPM.
excerpt
rpmrebuild is a tool to build an RPM file from a package that has already been installed in a basic use, rpmrebuild use does not require any rpm building knowledge. (On debian, the equivalent product is dpkg-repack).
Example
Say we want to repackage openssh-server.
$ rpm -aq | grep openssh-server
openssh-server-6.2p2-8.fc19.x86_64
Now package it:
$ rpmrebuild openssh-server-6.2p2-8.fc19.x86_64
/usr/lib/rpmrebuild/rpmrebuild.sh: WARNING: some files have been modified:
..?...... c /etc/ssh/sshd_config
..?...... c /etc/sysconfig/sshd
Do you want to continue ? (y/N) y
Do you want to change release number ? (y/N) n
result: /root/rpmbuild/RPMS/x86_64/openssh-server-6.2p2-8.fc19.x86_64.rpm
References
Best Answer
chroot
can take a command to run to this might work:Also,
rpm
has the--root
option so this is another option: