I have two separate projects that are built into RPMs using the maven-rpm-plugin.
Both packages have a postinstall script, which contains some duplicated code.
I would like to move the duplicated code into a single 'functions' script that could be inherited by both packages. Is this possible?
Write the common script as a standalone *.sh shell script that is installed and invoked in %post (or any other rpm scriptlet).
Remove the duplication of code by adding a dependency on whatever package you choose to install the common script (but avoiding dependency loops).
Related
Good morning, I am reading about the prepared scripts in MacOSX to use when creating a pkg for my application.
In particular, I have some doubts how to make sure that postupgrade script is used.
What I read till now is:
from here
The postupgrade script is run after files have been installed and before the postflight script if one is defined. This script is run only if the component has been previously installed. If the script does not return an exit status of zero, Installer will declare the installation has failed.
Ok then it seems that postupgrade will just run in automatic when an upgrade is done. BUT...from man pkgbuild, section --scripts scripts-path
Archive the entire contents of scripts-path as the package scripts. If this directory contains scripts named preinstall and/or postinstall, these will be run as the top-level scripts of the package. If you want to run scripts for specific bundles, you must specify those in a component property list; see more at COMPONENT PROPERTY LIST. Any other files under scripts-path will be used only if the top-level or component-specific scripts invoke them.
So, it seems I should add it to the component.plist, since they do not say anything about postupgrade. BUT it seems strange, I would put there more specific script, not the postupgrade script.
Reading more, I found it that refers to this, where there is written:
To determine whether a Package has already been installed or not, Installer.app is having a look at the content of the following directory: /Library/Receipts. If there's a file named PackageName.pkg within it, then the Package has already been installed, otherwise it's the first install.
Well, my application leaves no pkg file there, but yes it is present in the InstallHistory.plist.
Well, finally the question: should I set the upgrade script somewhere, for example in the component.plist file? The last link seems to be out of date, something has changed? How can I put a pkg file inside /Library/Receipts? Or better, how can be sure if my installation is indeed an installation and not an upgrade, or viceversa?
Thanks everyone, I am a bit confused...
Im trying to establish if it possible to create a deb package for the following app:
http://openfoam.org/download/4-0-source/
It uses an Allmake shell script which contains various standard shell commands and wmake commands to compile the source. wmake appears to be specific to this application but does call make:
http://www.cfdsupport.com/OpenFOAM-Training-by-CFD-Support/node25.html
https://github.com/OpenFOAM/OpenFOAM-2.1.x/blob/master/wmake/wmake
Is it possible to call the shell script from within a debian/rules file? or is there a better way of doing this if it is indeed possible?
Any assistance is much appreciated.
Indeed, the general idea of the debian/rules file is to run whatever commands are required to configure and install the upstream package into a location suitable for the dpkg toolchain.
Modern debhelper-based debian/rules files are typically extremely terse, because most typical packages adhere to build conventions for which good, very simple canned helpers are available, but traditional, more complex and explicit rules files are well-documented in older Debian packaging documentation.
Basically, the debian/rules file is a Makefile; it should have a binary target with the commands to build the upstream package into the Debian package root.
https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#rules is probably useful as a starting point - unless your needs are really arcane, the dh defaults will mostly make sense, and it allows you to easily override the parts which don't.
I know there are deployment packages but what are these? Can they contain bash scripts that do apt-get install?
Is there any way to build a lambda function that uses a particular AMI
You can run shell commands from inside your code(so technically you could run shell scripts) but you are charged for the time it takes your Lambda to execute - so installing a bunch of dependencies every time the Lambda starts up would be considered an anti-pattern.
You need to bundle all the packages and dependencies with your Lambda. This is done by uploading a zip file that contains the lambda function and all the dependencies.
You can see the official docs for the various supported languages here:
http://docs.aws.amazon.com/lambda/latest/dg/nodejs-create-deployment-pkg.html
http://docs.aws.amazon.com/lambda/latest/dg/lambda-java-how-to-create-deployment-package.html
http://docs.aws.amazon.com/lambda/latest/dg/lambda-python-how-to-create-deployment-package.html
I think your are looking for something like lambda-uploader. You can list out the python packages required by your lambda. If you come across a package that requires a couple of library files to run, you can include them as well. Like for example, the mysql-python package requires libmysqlclient.so and _mysql.so files to run properly.
It generates the .zip file for you and deletes it once it has been uploaded. This way, you can avoid manual packaging steps and make deployment a breeze.
I was wondering is it possible to run a configure script from another one? What I have is the situation where my own project uses autotools for config and make. So before any build a configure script is ran (as usual). But now I want to add another lib to my project which also uses the same build principle (It is necessary to run configure script before building a project). So instead of making my future users run two configure scripts, is there a way to automate this. (but without using a shell script - bash, perl, etc.)
Can this be done and if so, how??
I'd like to make my groovy script portable and I inserted in the first line:
#!/usr/bin/env groovy
The problem comes up when I run the script outside of its directory, it can't find libraries. I come from python world and all imports in python resolving relatively script's path. In groovy it seems I have to specify -classpath but I can't do that in the first #! line.
Any suggestions how to resolve it?
If the libraries are stored in a Maven repository that is accessible wherever you want to run it, one solution would be to use Grape to grab the libraries.
This provides several benefits:
You don't have to worry about the classpath at all
You don't have to distribute the libraries — just make sure Groovy is available on the client
Libraries are downloaded just once, so even if you upgrade the application, you only have to redistribute the .groovy file.
A simple example:
#!/usr/bin/env groovy
#Grab(group='commons-io', module='commons-io', version='2.3')
import org.apache.commons.io.FileUtils
... use FileUtils like normal ...
There's a lot of existing libraries available on mvnrepository.com already.
Even if you have non-public libraries, it's relatively easy to put your own libraries into a local / private repository.