I'm building an RPM installer with install4j. My installation contains few third party rpms that need to be installed, so after copying files to target directory, I want to run rpm -Uvh to install it.
I tried to mention this command as a post-install script in Media --> installer options tab, however when installing my RPM getting warning
warning: waiting for transaction lock on /var/lib/rpm/.rpm.lock
and installation stuck. I believe that third party install process is blocked by currently running process that making dead-lock.
How can I overcome it?
Thanks
Up to install4j 7.0.3, the RPM archive media file type does not support dependencies.
Starting with the upcoming 7.0.4 release, you can configure dependencies on the "Installer options" step of the media wizard.
Please contact support#ej-technologies.com to get a build where this is already supported.
Related
I am looking for a lightweight method to create rpm packages under MS Windows environments.
Actually I use Cygwin. I generate the rpm by using cmake(cpack). For cmake I need to install gcc to bypass the compiler check. For the rpm generation I have the rpm & rpm-build packages installed. When I am checking the size of the Cygwin dir it is around 2.2GByte. Quite a lot for generating a "simple" rpm.
Is there a "better" way to generate RPMs? Maybe in .net etc.?
I know I'm a bit late to the party, but I've started the dotnet-packaging project, which allows you to create RPM and Debian packages on any platform that hosts .NET/.NET Core. So that includes Windows.
You can either use it as a library or as a .NET command-line utility (e.g. you could just run dotnet rpm on your project and it would create a RPM file for you).
https://github.com/qmfrederik/dotnet-packaging has the code and a getting started guide, let me know if that works.
I want to build an RPM of OpenCV for a distribution of Oracle Linux. I have been reading various guides to making an RPM (see http://www.ibm.com/developerworks/library/l-rpm1/), and from Fedora's documentation, I read the following:
The RPM system will automate the steps to create an application, as
long as you configure the RPM with the proper steps, such as which
make targets to run. Unfortunately, configuring the proper steps is
not always easy. So before trying to make an RPM, you need to figure
out how to build the application or library you plan to package into
an RPM. Once you have figured out how to build the application or
library, you can set up a reproducible build. The RPM system can then
automate this build.
From this I gather that RPM doesn't install prebuilt libraries and binaries, but builds them from source. However, my experience tells me that when I download packages that I am just installing prebuilt binaries. Is this correct?
There are two different things. You can package an application using
rpm system using a spec file
The spec file is the recipe for creating your application. Once you have a spec file. You can use it generate a src rpm or binary rpm. Binary rpm is the rpm that you were referring.
The spec file specifies how to build/package your rpm. We use rpmbuild command to build the rpm.
Now you can use rpm command to install/uninstall/upgrade the rpm package.
Please don't be confused between rpm, the package AND rpm system, the engine responsible for building the rpm
I have to manage an Ethernet traffic card (my Linux target board(mips32)) having net-snmp 5.5 installed on it.
I want to upgrade it to latest net-snmp 5.7.3 and have successfully compiled net-snmp.
After that I had changed the all the libnetsnmp* library files, MIB text files and snmpd and snmptrapd daemons...but it gives errors like failed to open shared library ....can not find libnesnmp.so.20 files Why it is throwing this error even though I have updated net-snmp library files.
I am confused that what files of 5.5 has to be replaced by the 5.7.3, in order to upgrade my net-snmp package.
Also please guide me the steps to install a Fresh net-snmp package on any Linux board.
The net-snmp suite comes in 3 distinct Linux packages.
net-snmp (the snmpd agent and snmptrapd daemons, documentation, etc)
net-snmp-utils (various utilities e.g. for interrogating SNMP agents,
sending traps, etc )
net-snmp-libs (runtime libraries)
Have a look at https://stackoverflow.com/a/32093525/449347 to a more detailed listing of files in each.
Make sure you have updated ALL that you have installed.
EDIT ...
Paraphrasing http://www.betweendots.com/topic/45-install-the-latest-version-of-net-snmp/
When you have a CentOS box and type "yum install net-snmp", you'll get
version 5.5. If for some reason you want the latest version (5.7 at
the time of writing), then here's what you have to do:
yum remove net-snmp net-snmp-utils
Install dependencies: yum install perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker
Unpack and install net-snmp:
tar zvxf net-snmp-*.tar.gz
cd net-snmp-*
./configure
make
make install
Create an snmpd.conf and put it in /usr/local/share/snmp.
But follow above link for more info!
1) What is the difference between installing apache from "yum install httpd" and "source" ?
2) Why both installation methods create different path for httpd.conf file?
3) Are we doing source installations for specific requirements?
Installation from Source:
tar xvfz httpd-2.2.17.tar.gz --> ./configure --enable-ssl --enable-so --> make --> make install
Installation using YUM:
yum instll httpd
Please help me.
Thanks in advance
-Shishir
1) What is the differnce between installing apache from "yum install
httpd" and "source" ?
Installing distributor-provided package (eg. by yum) means installing precompiled, almost-ready-to-use binary version of application, whereas installation by source means building application from source, which involves compiling program source code into binary code.
Most notable differences are:
Building from source provides more flexibility - often applications can be configured to be built with different features. For example, you can decide whether you want to build Apache with support for SSL and whether you want to include support for PHP scripting and so on. On the other hand, binary packages are sometimes split into several packages, for example Apache modules (such as mod_php) can be installed as separate modules.
Installing from source is usually much more time consuming while installing binary package involves mainly copying files and running installation scripts.
Most often, latest versions of applications are provided in source form only - there is time gap before application is packaged and made available in repositories. On the other hand, application installed from repository will be automatically updated by package manager, while applications installed from source will have to be updated manually.
Installing binary packages need only package manager, whareas installing from source required working toolchain, mostly make, compilers (eg. gcc) and development version of third-party libraries.
Package manager handles dependencies for you. For example, Apache needs libapr, Apache Portable Runtime. When you install Apache using package manager, it installs libapr automatically for you. When you build from source, you have to install libapr first.
2) Why both installation methods create different path for httpd.conf
file?
Because different distributions have different guidelines for filesystem layout. RedHat packages follow RedHat guidelines, Debian packages follow Debian guidelines.
Source packages follow some "generic" guidelines.
3) Are we doing source installations for specific requirements?
That may be one reason for doing so. See point 1.
in addition to providing the software via package managers, is there a way to provide the software with all its dependencies packaged into one for download. i.e one big binary.
The goal is for users without permissions or with dependency issues to simply download the big binary and run it out of the box.
Note: Software can already be installed via apt-get but I want to offer the option to download it whole
You could try creating
rpm package for Suse/RHEL linux can be installed "rpm -ivh".
package (.pkg) in solaris and can be installed "pkg -d".