libhyperic-sigar-java: (System Information Gatherer And Reporter - Java bindings)
I know the way to install "libhyperic-sigar-java" in ubuntu to use
sudo apt-get install libhyperic-sigar-java
Now I want to install libhyperic-sigar-java in CentOS
How should I do ? Any RPM I can use ?
If you are using java, take a look to Kamon Sigar Loader
Provides convenient self-contained Sigar
classes with native library deployment and provisioning mechanism with JDK-only dependencies
for the following common use cases:
Java Agent: automatic extract/load at JVM start time
Programmatically: embedded library extraction
Framework Contract: OSGI bundle activation
here the documentation.
you should use yum. First search for the exact package name:
yum search java
then when you have found the exact name:
yum install libhyperic-sigar-java
(or whatever the exact package name might be)
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'm trying to install plone 4.3.4 on a SLES 11 SP3 64bit server via the Unified Installer. I've fullfilled all the dependencies listed in the readme.txt, but when I try to get the installer running with the command sudo ./install.sh --password=******* standalone I get the error message: which: no python2.7 in (/usr/bin:/bin:/usr/sbin:/sbin) Unable to find python2.7 on system exec path.
I find that rather strange as in the description of the unified installer it is said "The new Zope/Plone install will use its own copy of Python, and the Python installed by the Unified Installer will not replace your system's copy of Python. You may optionally use your system (or some other) Python, and the Unified Installer will use it without modifying it or your site libraries." on the Plone-Website.
So - what am I doing wrong???
I've just tried adding the parameter --build-python but had to find out that the libxml2-devel and libxslt-devel libraries that are available for SLES-11-SP-3 are sadly not up-to-date enough 2.7.6 instead of 2.7.8 and 1.1.24 instead of 1.1.26 respectively. So no joy there either. :-(
Is there any way to install the current version of plone on SLES 11 SP3 64bit?
Kate
The installer command:
./install.sh standalone --build-python --static-lxml=yes
worked perfectly for me. The installer downloaded and built the Python and libxml2/libxslt components necessary to remedy the terribly out-of-date (and vulnerable) versions included with sles11sp3.
System packages needed for the build were:
gcc-c++
make
readline-devel
libjpeg-devel
zlib-devel
patch
libopenssl-devel
libexpat-devel
man
All installed via zypper.
I'd advise not using sudo for the install. If you want to, you'll need to create the plone_daemon and plone_buildout users and the plone_group group in advance due to oddities in SUSE's adduser implementation.
Using the commandline installer, one can easily install Cygwin with a list of wanted packages like so
setup-x86.exe -q -p='tar,sed,<more packages>'
Is it also possible to fix the version of the packages, something like
setup-x86.exe -q -p='tar:1.2.3,sed,<more packages>'
(this obviously doesn't work)?
The short answer to your query is, No. Cygwin's setup -x86.exe does not give you the flexibility to specify version names along with package names. As per the official doc :
The basic reason for not having a more full-featured package manager is that such a program would need full access to all of Cygwin's POSIX functionality. That is, however, difficult to provide in a Cygwin-free environment, such as exists on first installation. Additionally, Windows does not easily allow overwriting of in-use executables so installing a new version of the Cygwin DLL while a package manager is using the DLL is problematic
There are however a couple of workarounds if you want to download a specific package:
Locate a cygwin mirror that hosts the specific version. Google for your version, and if you find a mirror hosting that version, simply use that mirror before running setup -x86.exe. [source]
Maintain a local pacakge repository and use the commandline options -q -L -l x:\cygwin-local\, where your downloaded package tree is in x:\cygwin-local\ [source] . You can learn how to build and maitain packages here
Compile and install the package after you've set up cygwin using make.
This is function that Cygwin's installer now provides. By default, when running from the command line, it will install the latest version of each package, but you can specify a version with =. For example:
setup-x86_64.exe -P git=2.35.0-1,vim
will install the latest version of Vim, and version 2.35.0-1 of Git.
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.
I have a project that runs on Debian and uses many packages provided from the Debian repositories.
Because of demand, I've looked into porting the project to CentOS, but found that many of the packages I require are completely missing - at least 10 dependencies would have to be compiled manually at install time on the users machine.
My question is, what is the best way to create an installer for the user's machine? Should I use automake tools (with the standard ./configure, make, make install), to compile the required libraries, or is this a non-standard approach. Note that my app doesn't actually need to be compiled since it is written in Python, so is it weird to do a "make", when you're not compiling your own app?
Should the configure script just warn the user that package X is missing, and let them handle the rest?
Should I roll my own dependency checker by runng pkg-config manually a few times for each library required, and exit if something is missing?
I'm quite new to this, so any tips to get me moving in the right direction are appreciated.
Edit: I am familiar with RPM and yum for red hat base distros, but CentOS is missing many multimedia packages that I require. An example of one of my package dependencies is "liquidsoap" which is a programmable audio engine: http://savonet.sourceforge.net/
This is available on Debian, but not Redhat/Centos
See this link on CentOS package management.
http://wiki.centos.org/PackageManagement/Yum
CentOS is redhat based and does not use .deb packages by default. However apt package management has been ported to tons of platforms, you may be able to use a port for centOS
If you use YUM whatever packages you need will be there for your application as redhat distros need all the same things that any other distro does.
EDIT: To get the details out of comments
Packages not available on the target platform either have to be built (possibly as a port) on the target platform and then shipped in the ported package (in this case YUM), or code needs to be modified and forked to use packages which already are available on the target platform. The choice depends on which is worse, or which is even possible given your constraints.