I have a set of programs for analyzing radiation data and I want to build packages for Red Hat Linux versions 4.x - 6.x. Is it possible to build these packages on a single build server running a single version of Red Hat Linux or do I need to build the version 4.x package on a server running version 4.x and the version 5.x package on a server running version 5.x?
If I can build packages for several versions on a single server, must that server be running the newest version or the oldest version of the OS?
You need to build toolchain for different OS environments (toolchain for Redhat 4.x and 5.x) and with in toolchain you can build packages for specific OS. toolchain is like a chroot environments.
You can create multiple Virtual machine using KVM and build many version of packages using single node..
You can use UML (User Mode Linux) which is quite interesting... Check out following Link
http://uml.devloop.org.uk/howto.html
You can build your packages in a chroot jail. You can use mach to do so.
Here's a tutorial on building packages with mach you could refer to, though it may be outdated.
Related
I have a Java application using Postgres. The installer is created via Install4J for Windows and Linux.
The installer also handles the installation of Postgres on the system. So there's a Postgres package included in the installer resources. In the past EDB offered packages for Windows as well as Linux but they stopped offering the Linux packages after version 10.
Is there a way to create a package of a newer version from the sources? Should be in the style the old versions were packaged in. So that the package would work on all Linux distributions, e.g. Debian, CentOS...
For example, I have a server running Ubuntu 16.x that hosts a set of Docker containers that are running FROM node:x.x.x-stretch. The stretch variant is built off of Debian Jessie (the same version Ubuntu 16.x is built off of).
Is there any reason I shouldn't be using the latest Node image (node:x.x.x-buster), where -buster is built off of Debian 10?
From what I understand, this means that my node image would be more up-to-date / supported longer at the small cost of having less shared with the underlying host OS. Am I missing anything?
The main reason why people don't automatically update to the latest version, is due to package dependencies. It's difficult to keep track of what packages are dependent on what version of node, let alone what version of other packages.
I'm working with Node.js 8.9.4, the current LTS version.
If I download the 64 bit Linux binary distribution of that version from the Node.js website (https://nodejs.org/dist/v8.9.4/node-v8.9.4-linux-x64.tar.xz), then the node executable it includes will run on Red Hat Enterprise Linux 6. (I need to be able to target this version of RHEL).
I have also built Node v8.9.4 from source, following the instructions at https://github.com/nodejs/node/blob/master/BUILDING.md#building-nodejs-on-supported-platforms. Doing this required gcc 4.9.4 or newer, as per that page, because C++11 support is now required.
However, the node binary that results from that build will not run on RHEL 6, because the standard C++ library (libstdc++.so) that ships with RHEL 6 is from GCC 4.4.7. It's necessary to reference the libgcc and libstdc++ from the newer version of GCC that was used to build node to get it to work.
I think this means that the Linux binary distributions on the Node.js website are not built using the process described in the build instructions - if they were, they would not run on RHEL 6.
Is there any information on how the binary distributions of Node.js are built? Are there some options to the configure script that I'm missing?
(The reason for this question: I'm trying to build a Node C++ add-on, which needs to target RHEL 6, and hitting the same problem with the version of gcc required to build it vs. the version of the GCC/C++ runtime on RHEL 6. Yes, I could distribute the runtime libraries with my application, but there is obviously a better solution, because the binary distribution of Node is using it).
For easy deployment, I'd like to ship an installation of Postgres as part of the application. Is it possible to include an already compiled and runnable version of Postgres that can be launched as process? I was able to do such thing with a Windows and MacOS version, but haven't found anything about Linux on that matter yet. Perhaps someone has tried this before and can share some insights...
You haven't stated what linux OS you're using.
Assuming it's a Redhat variant why not package your application as an RPM package? You could then declare a dependency on the standard Postgres package which would be automatically installed yum. Same principle applies if you're using Debian based systems, just a different packaging format.
From the user's perspective the OS's native packaging format is always the easiest way to install your application. Just requires effort to package it properly.
You can find cross-platform binaries from these pages on PostgreSQL official website:
For easy GUI .run installers, use links provided at http://www.enterprisedb.com/products-services-training/pgdownload.
If your target machine has no X installed on it, or you want to automate installation process with shell scripts, then you can download RPM or Deb packages from http://community.openscg.com/se/postgresql/packages.jsp
I found these links on http://www.postgresql.org/download/linux/ubuntu/, under "Cross distribution packages" and "Graphical installer".
I quote from those pages:
Note: The cross distribution packages do not fully integrate with the platform-specific packaging systems.
You must have root priviliges to install these packages, however, none of your systems library files will be altered. The supporting libraries that these binaries require are included locally as part of the install. This is the "special sauce" that allows identical binaries to run on different linux distro's.
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.