Good afternoon,
I was able to build my project into a deb package using:
fakeroot dpkg-deb --build mypackage
Next, I can install the package using
dpkg -i mypackage.deb
Everything is installed and copied correctly when I do this, however I would like to run a few bash commands after the package is installed.
I understand this needs to be done using the postinst file in the mypackage/DEBIAN directory
I have seen a few examples of this script online, but no clear explanation of how to write one and how to include it in the build.
How do I make sure fakeroot dpkg-deb includes this script, is placing it into DEBIAN directory enough?
There is a case structure in the postinst script, what is this for, and where do I place the bash commands to execute in that script
If I install the package with dpkg - i mypackage.deb is this enough to run that script?
An example script I would like to make is shown below.
What do "configure, abort-upgrade, abort-remove, and abort-deconfigure" stand for.
What does the "update-alternatives" line do.
Thank you for your help,
postinst file below.
#!/bin/sh
set -e
case "$1" in
configure)
# EXECUTE MY BASH COMMAND
echo /usr/local/lib > /etc/ld.so.conf && ldconfig
;;
abort-upgrade|abort-remove|abort-deconfigure)
exit 0
;;
*)
echo "postinst called with unknown argument \`$1'" >&2
exit 1
;;
esac
update-alternatives --install /usr/bin/fakeroot fakeroot /usr/bin/fakeroot-ng 5 \
--slave /usr/share/man/man1/fakeroot.1.gz \
fakeroot.1.gz /usr/share/man/man1/fakeroot-ng.1.gz
exit 0
First, here is possibly the most relevant documentation: Debian Policy Manual: Package Maintainer Scripts and Installation Procedure.
Second, the very most important thing to remember when writing or dealing with maintainer scripts is that they must be idempotent. Assume the script will be run many times in succession, and make sure things still won't break if so.
To answer your questions directly,
Putting it in the DEBIAN directory is correct, when building with dpkg-deb. If you were instead using Debhelper for a safer or more convenient build setup, you might put the postinst in debian/$packagename.postinst.
The postinst script can be called in a number of different situations. The "case" statement you can find in many (most?) postinsts is meant to check which situation it is. Generally speaking, it makes sense to take most postinst actions in all of the possible situations, and that's why they are grouped together in one script. But sometimes it is better to differentiate. I'll explain the different scenarios under #4.
Yes. A successful installation of a deb package (whether by dpkg -i, apt-get install, or whatever) must involve a successful run of its preinst and postinst scripts, if present. It is possible to "unpack" a deb without running any maintainer scripts, but that is not considered "installing".
These "action" names correspond to the different situations in which a postinst can be run.
configure: A package is being installed or upgraded. If the package wasn't installed before, $2 will be empty. Otherwise $2 will contain the old version number of the package; the version from which you are upgrading.
abort-upgrade: An upgrade operation was aborted. As an example, I have version V1 of mypkg installed, and I try to upgrade it to V2. But the preinst or postinst of V1 fail to run successfully, or there is a file conflict. dpkg stops trying to install V2, and re-runs the postinst from V1 (with the "abort-upgrade" action) in case any state needs to be restored.
abort-remove: A remove operation was aborted. For example, if I ran "dpkg -P mypkg", but mypkg's prerm script failed to run, or something else happened that made dpkg think it could not safly uninstall mypkg. So it runs mypkg's postinst again (with the "abort-remove" action) in case any state needs to be restored.
abort-deconfigure: As you might guess, a deconfigure operation was aborted. "deconfiguring" is sort of a half-removal action used when a package being installed conflicts with others already installed. To make the explanation short, if the abort-deconfigure action is being run, the postinst is expected to restore any state that might have been undone by the prerm script with the deconfigure action.
For lots of additional nitty-gritty details, see the great charts and explanations at https://people.debian.org/~srivasta/MaintainerScripts.html .
The "update-alternatives" command updates entries in the Debian "alternatives" system. See the man page. In this specific case, the command is telling Debian that "/usr/bin/fakeroot-ng" is an alternative for the fakeroot command. Depending on the priority of this alternative and the priority of other registered alternatives, and the preference of the user, fakeroot-ng might now be invoked when someone runs "fakeroot".
Just one think about this line :
echo /usr/local/lib > /etc/ld.so.conf && ldconfig
According the Debian Policy, you shouldn't modify ld.so.conf
A simple alternative is to do something like that :
In your postinst script :
/usr/local/lib > /etc/ld.so.conf.d/EXAMPLE.conf && ldconfig
and in your postrm script :
rm /etc/ld.so.conf.d/EXAMPLE.conf && ldconfig
Related
I have a script that must be run in Perl 5.10.1, although my university's linux cluster system uses the most recent version of Perl. I tried to install Perlbrew, but I don't think it worked.
I'm not sure how to specify the perl version in the shebang because of how I call/run this script. There is "cluster.pl", which is run by running "./command.txt".
Also, I don't think I can install Perlbrew because it's the university's linux system: After copy-pasting the installation commands, my terminal screen said the perlbrew patch was installed, but when I used "perlbrew install perl-5.10.1", it would say "command perlbrew not found" I don't know how to run the script
As of now, cluster.pl has this shebang:
#!/usr/bin/perl
One related question said to write this in the command line
/program/perl_v5.6.1/bin/perl scriptName.pl
#OP needed to use version 5.6.1, unlike me (I need 5.10.1)
However, I don't know whether "program" is OP's directory or a mandatory part of the path
Below is command.txt, which has the necessary input arguments:
#this is command.txt
./cluster.pl Datachr1 2 galGal5.Chroinfo.txt
Essentially, where would the suggested shebang go? Would I include "program" in my path too?
If you wrap your script in Perl's packaging framework, this is handled for you automatically. When it installs scripts, it changes the shebang line with the actual perl. You end up with something like this at the top of the file:
#!/usr/local/perls/perl-5.30.0/bin/perl
eval 'exec /usr/local/perls/perl-5.30.0/bin/perl -S $0 ${1+"$#"}'
if $running_under_some_shell;
#!/usr/local/bin/perl
You might try this with my app-rhich distribution. Download the tarball and run the Makefile.PL with the perl you want. Run make and it builds stuff into the blib staging directory. You should see the modified shebang there:
$ /Users/brian/bin/perls/perl5.30.0 MAkefile.PL
Checking if your kit is complete...
Looks good
WARNING: Older versions of ExtUtils::MakeMaker may errantly install README.pod as part of this distribution. It is recommended to avoid using this path in CPAN modules.
Generating a Unix-style Makefile
Writing Makefile for App::rhich
Writing MYMETA.yml and MYMETA.json
$ make build
make: *** No rule to make target `build'. Stop.
$ make
cp lib/App/rhich.pm blib/lib/App/rhich.pm
cp script/rhich blib/script/rhich
"/usr/local/perls/perl-5.30.0/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/rhich
Manifying 1 pod document
Manifying 1 pod document
brian#otter app-rhich (master)[3125]
$ more blib/script/
#!/usr/local/perls/perl-5.30.0/bin/perl
package rhich;
use strict;
use warnings;
However, if your path to perl is a symlink to some other perl, this can get confused. I don't use perlbrew because I don't think it adds much other than saving you looking up a download URL. I install multiple perls (and How should I install more than one version of Perl?) and can use paths to them so I know which version using. There's a similar problem with env depending on how you set up your path. How you handle that is based on how you decide to manage things, but it's these sorts of questions that show that the tools of convenience aren't really that convenient.
As a follow-up of this question, I started building MPICH2 from source. I found this tutorial: Installing MPICH2 on a Single Machine and so far what I did is this:
./configure --disable-f77 --disable-fc --disable-fortran
[seems to be OK]
make; sudo make install
[long output with one warning]
libtool: warning: relinking 'lib/libmpicxx.la'
root#pythagoras:/home/gsamaras/mpich-3.1.4# mpich2version
bash: mpich2version: command not found
What am I doing wrong? Notice that I had first installed MPICH2 with apt-get and in order to remove it, I did:
apt-get remove --purge mpich2
apt-get autoremove // which might removed something that I need now
Tomorrow, I am going to try this: Getting And Building MPICH (which with first attempt failed to work in the autogen.sh part).
EDIT_1:
I couldn't get it to work, will try a combination of the two tutorials and report back. I did a configure and then the make from the other tutorial, failed too.
EDIT_2
This may shade some light about where it got installed (by following the first tutorial):
root#pythagoras:/home/gsamaras/mpich-3.1.4# which mpiexec
/usr/local/bin/mpiexec
root#pythagoras:/home/gsamaras/mpich-3.1.4# which mpirun
/usr/local/bin/mpirun
You installed into /usr/local, which is an OK way to do things. The README instructions you followed suggests another way which will not require administrative privileges.
I like to install into /home/robl/soft/mpich-whatever , so I can have different compilers, versions, configurations, etc. such flexibility is probably overkill for you, but it's one strategy.
To your question:
root#pythagoras:/home/gsamaras/mpich-3.1.4# mpich2version
bash: mpich2version: command not found
First, the command is now mpichversion, not mpich2version -- it's possible you were following an old tutorial.
Second, your shell might not know about the newly installed binaries. hash -r (at least on bash and tcsh) will tell the shell "forget about what you think you know about my file system and look harder".
I found this mpich-3.0.4-README, who seems to provided the solution.
Long story short, it says (it assumes you want to build 3.0.4 version, I did it with 3.1.4 (available here)):
tar xzf mpich-3.0.4.tar.gz
cd mpich-3.0.4
// you might want to disable fortran compiler (see the README I linked above)
./configure --prefix=/home/<USERNAME>/mpich-install 2>&1 | tee c.txt
make 2>&1 | tee m.txt
make install 2>&1 | tee mi.txt
PATH=/home/<USERNAME>/mpich-install/bin:$PATH ; export PATH
which mpicc
// should return something reasonable (with your directory)
mpiexec -n 2 ./examples/cpi
Now, the option with the machinefile does not work, because ssh needs a password, but that's another question.
I'm using vagrant shell provisioning here.
I've installed on my vm Node.js along with many other packages.
I want to avoid running parts in my provisioning script when I don't need them.
For example - I already successfully installed via my script Node.js & nginx, so when I want to add additional packages like mysql or redis, I want to add it to the script, I want to run the script to test that it runs properly, but I DO NOT want to re-install Node.js or nginx again...
I need a simple conditional statement that would detect if a package is already installed, and install it only if it is not already installed.
Is there a generic check or will it be different from package to package?
Thanks
Ajar
dpkg -s <pkg-name> 2>/dev/null >/dev/null || sudo apt-get -y install <pkg-name>
This should be what you're looking for.
What's going on here:
This is a conditional assignment of the form <condition> && <value if true> || <value if false>
The first part of the expression uses dpkg to check to if the package is installed, suppressing the output. The second part is evaluated if the condition returns false. The "true" case is omitted.
This dependes on the Linux distribution you are using. Usually, a package manager comes with some kind of mechanism to skipp already installed packages.
For Ubuntu, this is built in - running apt-get install nodejs with Node.js already installed will not reinstall it; it will skip the target (unless there is new version available)
For ArchLinux, you can add run pacman -Sy node --needed to skip already installed packages.
A platform-independent mechanism would be to check if the executable (or any other known file for that package) exists. In Bash, you can do:
which node > /dev/null && echo "Yup, this is installed"
(the > /dev/null part supresses which's output - it prints the path where the found executable resides; we do not care about that, we only want to know if it is installed)
If you want to avoid writing custom Bash scripts for such basic checks I can recommend that you configure your boxes with tools dedicated for exactly what you are trying to achieve. The usual suspects here are:
Ansible
Puppet
Chef
CFEngine
All of these are supported by Vagrant so integrating them should not be a problem. You can find detailed guides on integrating these into your existing Vagrant recipe here.
PS. For a simple exapmle you can check out my Ansible provisioning recipe for Banana Pi machine running ArchLinux (note: it does not really follow best practices, but it might be a good starting point). There are many examples available online, check them out, too.
I tried to upgrade Perl and put my computer into a complete mess
I am currently running RHEL6.5, 64bits, and this is the thing:
I had perl-5.10.1 installed, and working nice. this came installed,
and I could see it from yum
I wanted to install Padre, an Perl IDE, but that required at least v5.11 [I was so close! :( ]
There were no newer version for Perl in the repos that I have access to (and I have a limitation that I can't add new repos)
I got approval from my boss to download perl-5.20 .0 from www.perl.org and tried to install it
... and the mess begins!
First I installed the new perl with my own id, and that pushed perl to somewhere under my home dir
I tested with 'perl -v' and could see that my env was pointing to the newer install, however, yum never recognized it (not really a problem)
When I tried to install Padre, seems somehow it had the hardcoded the original perl (from /usr/bin) and still claiming for something as newer as 5.11.
Trying to fix it, I did installed the new perl again, now using root, to make it push perl under /usr tree ... it installed, but pushed perl to /usr/local/bin, instead of /usr/bin
So again, I had one more perl install but Padre still looking for the one on /usr/bin
I give up about Padre, and deleted the files related to it, as well as the perl installed on my home dir, however a couple of perl scripts that I had already coded now are throwing errors like:
perl -cw "xmltest.pl" (in directory: /home/myid/scripts/xmltest.pl)
perl: symbol lookup error: /usr/lib64/perl5/auto/Data/Dumper/Dumper.so: undefined symbol: Perl_Istack_sp_ptr
Compilation failed.
... and Data::Dumper in not the only one ... every time I disable one of the modules, another one hangs in the same, or similar way
From what I read about this, seems that this issue is related to modules that were originally installed for one perl version, and are being called by another, however, I already forced the modules that I use to be reinstalled directly from CPAN, and they still failing
Question: How can I, safely, get free from this current perl installs, and perform a new clean install be able to use it w/o these versions conflicts?
My major concern are about the numerous apps that I have that depends on Perl, and I my not broke then on a uninstall
Any help will be much appreciate.
You should:
cleanup
clean (comment out) your ~/.profile from any unwanted paths, and so on
clean any new perl installation from your $HOME (move to safe place for sure)
in short, try return your environment into previous working state
relog, (logout, login)
repair your system perl. Thats mean,
read #Sam Varshavchik's answer
reinstall it from your distribution, using your package manager (5.10).
this step should overwrite the mess you caused.
test it !
don't continue until youre ensured, everything working right as before.
Lesson learned: never overwrite your system perl
learning
read thru perlbrew.pl
repeat previous step once again, especially with the
the homepage
http://perlbrew.pl/Perlbrew-and-Friends.html
https://metacpan.org/pod/App::perlbrew
https://metacpan.org/pod/perlbrew
installing perlbrew
run the installation command \wget -O - http://install.perlbrew.pl | bash
should finished without errors
follow the instructions how to modify your startup file e.g. ~/.profile or such... (you need to add one line to the end)
check your ~/perl5/perlbrew/bin should contain prelbrew and patchperl
relog
setup new perl, run
perlbrew init #init environment
perlbrew available #show what perl you can install
perlbrew install 5.20.0 #will take few minutes - depends on your system speed
perlbrew install-cpanm
perlbrew list #check
perlbrew switch perl-5.20.0 #activate newly installed perl 5.20
Check your installation
in the ~/perl5/perlbrew/bin you should have 3 scripts: prelbrew , patchperl , cpanm
perl -v should return 5.20
type cpanm - should return ~/perl5/perlbrew/bin/cpanm
You're done.
CPAN modules
You can install new modules with cpanm, like:
applications
cpanm cpan-outdated
cpanm App::Ack
cpanm Unicode::Tussle
cpanm Perl::Tidy
cpanm Perl::Critic
collections
cpanm Task::Moose
cpanm Task::Plack
cpanm Task::Unicode
modules
cpanm Path::Tiny
cpanm Try::Tiny
cpanm JSON
cpanm YAML
etc...
Check the ~/perl5/perlbrew/perls/perl-5.20.0/bin/ for new commands
You will need update your own perl script's shebang line to
#!/usr/bin/env perl
I hope don't forget anything, maybe other more experienced perl-gurus will add/edit/correct more.
Anyway, in the reality the steps 5,6,7 are much easier as sounds (by reading this) and could be done in few minutes.
On rpm-based Linux distributions, you should never install system software manually, like this, by trying to compile and build it yourself. RHEL's package management tool, rpm, performs an important function of keeping track of dependencies between packages, and prevent package conflicts.
The errors you showed are precisely the symptoms of a corrupted system Perl installation, and rpm exists precisely to avoid this sort of thing happening. Manually building and installing random tarballs completely bypasses the safety net that rpm provides.
There's no cookie-cutter recipe for recovering from a corrupted system install of a critical system rpm like perl, but in general:
1) run "rpm -q" perl, this will show you the exact version of the perl rpm package that rpm thinks should be installed.
2) go to the RHEL installation media/directory, verify that it contains the same perl-.x86_64.rpm package. If you previously installed RHEL updates, it's possible that you already updated perl, so look for the version that rpm tells you have installed in the RHEL update directory, and verify that you have the correct rpm package.
3) Execute:
rpm -ivh --force perl-<version>.x86_64.rpm
This will reinstall the original perl RPM package that was previously installed. Your problem is not only that you have extra versions of perl installed, but that it's likely that some of your custom perl builds have clobbered the system perl package, and uninstalling them won't help, you have to reinstall the system perl.
4) In RHEL, many perl modules are installed as separate packages. The above process should be used to reinstall every perl rpm package that you have installed. Execute:
rpm -q -a | grep '^perl'
This will give you a list of all Perl packages you have installed. You will need to repeat this procedure for every Perl rpm package.
It's not a 100% guarantee that this will fix everything, there could be other things wrong too, but this is a good first step towards recovery.
What I have done:
From #Sam-Varshavchik answer:
Found the previous perl rpm in my yum cache, and installed ...
rpm -ivh --force perl-<version>.x86_64.rpm
Checked for others "perl*" previously installed packages ... there were +260 so saved it in a file rpm -qa "perl*" > /tmp/perl.pkgs
With +260 packages to install, I realized that do it manually would take too much time, so it was time to put some ksh skills in practice ...
I checked at my yum cache and found ~130 of the +260 packages, so
took out from the list the base perl package (that I already have installed);
for those in the cache, I decided to install then with rpm, in the same way as the base package;
for those that I did not have handy, I used yum, which would download and do the same
of rpm, so ...
CACHE="/var/cache/yum/x86_64"
for perlpkg in $(cat /tmp/perl.pkgs)
do
FILE=$(find $CACHE -name "${perlpkg}.rpm")
if [[ ${FILE} != "" ]] ; then
rpm -ivh --force ${FILE}
else
yum -y reinstall ${perlpkg}
fi
done
From #jm666:
Installed perlbrew (was able to got it from my auth repos, so got it using yum) and using perlbrew, installed 5.20.0 localy
TODO: Didn't got any additional modules and neither Padre yet ... need to learn more about the way perlbrew works and isolate the installed version away from the system perl
Once again, thanks #Sam-Varshavchik and #jm666 for your support ang guidance
I'm complete noobs in shell script what i want is shell script that determine a list of library/package currently installed if not install them without user permission
What I want is to determine the library/package is currently installed or not in system
I'm aware of aptitude search command but I looking for a better solution
e.g I have define(in shell script) check for readline library/package now how can I from inside the shell script (I want to create) know that readline package is currently installed or not.
Any idea or suggestion would certainly help
What I want is to determine the library/package is currently installed or not in system
dpkg -s does not require root permission, and will display package status details.
Example shell script:
#!/bin/sh
for P; do
dpkg -s "$P" >/dev/null 2>&1 && {
echo "$P is installed."
} || {
echo "$P is not installed."
}
done
Usage is:
script.sh package1 package2 .... packageN
For simply doing the test, it would seem that you could grep the output of a command such as ldconfig -p for your library of interest.
Or you could supply a tiny test program linked against the desired library, try running it, and test for non-failure.
If you are trying to set up a dependency check, the proper solution is to create a dummy package which Depends: on the packages you need to have installed. There is a tool called equivs which somewhat helps with this. (However, it has been criticized as being "over-engineered"; certainly, if you are familiar with the format of Debian packages, you might not need a separate tool if your requirements are this simple.) Then you just install this package and it will pull in the packages which are specified as dependencies.
You still have to know that the library which provides libreadline.so is libreadline5-dev. Debian package search can help find the package names you need to put in Depends:
You can probably do what you want with dpkg