I am revising one of our in-house RPMs that adds to the nagios package.
Originally our package would alter some files that were installed by nagios.
My new package undoes this methodology and takes an additive approach.
Is it possible to do something like this in the %pre section?
%pre
rpm --erase nagios
rpm --install nagios
When I run this it hangs here:
warning: waiting for transaction lock on /var/lib/rpm/__db.000
John
No way that I am aware of. If you need to do something special when nagios is modified, you can use %triggerin and %triggerout. I believe %triggerin will be executed when you install your RPM if nagios is already installed, but I don't remember offhand where in the sequence it will happen.
Related
I trying to get set up with Variant Effect Predictor (VEP) on the command line. I'm following the setup tutorial but I'm encountering some errors around dependencies. I'm also quite new to the command line so if anyone is able to break down the solution too then I'd be very grateful. Thanks!
Tutorial: https://www.ensembl.org/info/docs/tools/vep/script/vep_tutorial.html
VEP requirements: http://www.ensembl.org/info/docs/tools/vep/script/vep_download.html#requirements
I also have Perl v5.32.1.
What I've done:
I installed dependencies (listed in the requirements page) with the following commands:
- sudo -s cpanm DBI
- sudo -s cpanm Archive::Zip
- sudo -s cpanm DBD::mysql
For DBD:mysql, I got the follwoing message:
--> Working on DBD::mysql
Fetching http://www.cpan.org/authors/id/D/DV/DVEEDEN/DBD-mysql-4.050.tar.gz ... OK
Configuring DBD-mysql-4.050 ... N/A
! Configure failed for DBD-mysql-4.050. See /root/.cpanm/work/1626111140.5937/build.log for details.
Trying it out anyway, I ran perl INSTALL.pl (from the tutorial page) and got the message below. I would like VEP to run in online mode too if possible.
`WARNING: DBD::mysql module not found. VEP can only run in offline (--offline) mode without DBD::mysql installed
http://www.ensembl.org/info/docs/tools/vep/script/vep_download.html#requirements
Hello! This installer is configured to install v104 of the Ensembl API for use by the VEP.
It will not affect any existing installations of the Ensembl API that you may have.
It will also download and install cache files from Ensembl's FTP server.
Checking for installed versions of the Ensembl API...done
Setting up directories
Destination directory ./Bio already exists.
Do you want to overwrite it (if updating VEP this is probably OK) (y/n)? y
- fetching BioPerl
- unpacking ./Bio/tmp/release-1-6-924.zip
ERROR: Unable to unpack file ./Bio/tmp/release-1-6-924.zip without Archive::Extract or tar/unzip/gzip`
You show us this error:
Configure failed for DBD-mysql-4.050. See /root/.cpanm/work/1626111140.5937/build.log for details.
So looking in there will give you more clues about what the problems are. Without that, we can only guess.
But we can make educated guesses. The DBD::mysql distribution comes with a file called DBD::mysql::INSTALL which will talk you through some of the problems you'll find while installing this module.
It's important to note that DBD::mysql is a wrapper around MySQL's client libraries. They are written in C, so you'll need a C compiler installed in order to build DBD::mysql. You'll also need the client libraries and the development versions of the client libraries (for the C header files that you'll need to compile the module). On Ubuntu, those packages are called "libmysqlclient" and "libmysqlclient-dev". If you don't have a C compiler, then you'll want to install "gcc" too.
But this is all getting a bit complicated. There's another, simpler, approach. If you're using the system version of Perl (the version that was installed as part of the operating system and probably lives in /usr/bin/perl) then I'd recommend using the pre-build Ubuntu version of the package, which you can install by running:
$ sudo apt-get install libdbd-mysql-perl
Installing that version uses the OS's own package manager, and the package manager knows which other packages are needed in order for it to work - so it will install those as well.
People will probably complain that you're better off installing the modules from CPAN as it gives you more flexibility and allows you to use more up-to-date packages than the versions from your OS repos. And they're right. But, honestly, if you're a non-Perl programmer who just wants to get an application up and running, this is by far the simplest approach.
(But, as I said above, this is all guesswork as you haven't shared the most important errors with us.)
In maximum rpm under the section on the %pre install script, it mentions that it's rare to use the %pre script. In fact, it further states that (at that time anyway) none of the 400+ RedHat packages used the %pre script.
I would think the %pre script would be the ideal location to stop the existing service before installing files over top of the currently installed version.
Is my thinking wrong? How is it that RedHat got away with never using %pre during upgrade for this purpose in any of their service packages?
Yes %pre is much more commonly used than when "Maximum RPM" was written in 1997. That doesn't change the fact that %pre should be used "rarely".
The reason is that %pre prevents installation (and may cause an entire
transaction to fail if there are needed install time dependencies).
Stopping a service in %pre and restarting in %post opens a larger window
where the service is not running than simply restarting a service in %post
The already running service typically reads its configuration files
only on startup (and so rpm can replace files while daemon is running).
And running executables have a reference count on the file system and so
continue to run even if the file that was executed was removed/replaced
by a newer package.
Well, I went and did the research I should have done before asking this question. I downloaded several service packages from RedHat 7.1 and ran:
rpm -qp --scripts <package-name>.rpm
I found out 1) that it's no longer true that %pre is not used. Even among the few that I checked a couple of them used %pre, and 2) it appears that most services just allow rpm to overwrite their data files and binaries during upgrade, and then use the upgrade portion of the %postun (post uninstall) script to restart (or try-restart) the service.
I would have thought this rather unsafe, as while you're writing over data files (especially) during upgrade, the old running service might get confused. It seems to me ultimately it's safer to stop the service during upgrade on %pre and start it again on upgrade during %postun... but that's just me.
I have spent all day trying various things and made no progress whatsoever.
I am compiling an rpm package for my application (MyApp.rpm), for RHEL6 64-bit, which requires a third party, 32-bit driver package called aksusbd.rpm. Now, aksusbd.rpm in turn requires compatibility mode, provided on RHEL6 by glibc.i686.rpm.
So somewhere in my spec file for MyApp.rpm I have:
MyApp.spec
Requires: glibc(x86-32)
Requires: aksusbd >= 1.14
What it does during installation (yum install MyApp) is, installs aksusbd first, which fails with no 32-bit compatibility installed. Then just to tease me, immediately after installs glibc. So when its all over I can type
yum install aksusbd
and it works this time because glibc is now installed.
How on earth do I teach it to do better than this!
(growl)
You can follow Aaron's suggestion and tweak the third party RPM you have with rpmrebuild. It allows you to modify the requires spec of the RPM package:
rpmrebuild --package -n --edit-requires <your third party rpm package>
It's a hack but just for the requires tags in the RPM I would not be concerned.
First off I'd suggest putting the requires on the same line. Just separate them with a comma, they should then go in the order you've specified. If it doesn't and you're on RPM version 4.3 or below, you can use the PreReq tag as specified in the rpm.org docs about half way down the page.
If neither of those solutions works, or you are on a version of RPM greater than or equal to 4.4 I would imagine something else is going on that is causing a problem. I'd start by creating a new spec for some 'fake' project that specifically targets the issue of glibc not being installed before aksusbd. If that works we know it's something with your MyApp.spec, if it doesn't work then I'd suggest reviewing the naming convention of glibc, perhaps there is some kind of issue with how it's interpreting your (x86-32).
Sounds like the aksusbd RPM is what needs to be fixed - they need a Requires or Requires(pre) set. File a bug with the driver vendor.
I had exactly the same problem (and same in YUM groups). If Forrest suggestion to put requires in same line works for you, please let us know.
Otherwise, you can try to add an RPM that only requires aksusbd and add it to requires list. If YUM installs dependencies in an Alpha-beta order, name it something between aksusbd and glibc and it might work.
I was using ubuntu 12.04 until 12.10 was released. I used ubuntu for software development and after installing 12.10, i noticed that the perl version (5.14) shipped with 12.10 does not include the Switch.pm module needed while building WebKiT-GTK.
Looking around on the internet i found few suggestions indicating that i should install something call p5-switch from something called ports. I have looked around and was not able to get this done. I am not a perl guy and have no idea where i can get this package.
Can someone please help me as to
1. Where to download the package for ubuntu 12.10
2. In case it is not a .deb, How do i install it.
OR
1. At least be able to downgrade the perl installation to something lower than 5.14
Thanks and Regards
~Sameer
sudo apt-get install libswitch-perl
will install it for you.
"ports" is a *BSD packaging system of sorts, not what you should be looking for.
You can find what package has a particular perl module by going to packages.ubuntu.com, entering Module/Name.pm (in this case, Switch.pm) in the "Search the contents of packages" form and checking "packages that contain files whose names end with the keyword" and selecting the desired distribution, then making sure you ignore false hits like CGI/Switch.pm in the results. Debian has the identical search for its packages at packages.debian.org.
(Note that Switch.pm has serious limitations, was never really intended to be used in production, and should certainly not be used in new code.)
Do make sure you've checked properly that there isn't the Switch module available via apt. If it is available, that's the one you want.
No, then you've two options the longer, correct way and a shorter way that's not quite as clean.
1. Longer
Install cpanm and perlbrew with apt. The perlbrew tool lets you install a complete version of Perl from scratch in a separate directory. Set up a user for your webkit building, run perlbrew as that user, install your perl. Then, use cpanm to install required modules and you are done. A bit of googling will get you step-by-step examples of how to use these tools. If anything goes badly wrong, you can just delete all the files in that user's home directory and start again - all you waste is a little time.
The reason experienced Perl people prefer this is that it keeps the perl you want for webkit-gtk separate from your system perl that ubuntu's packages will expect to be unchanged from the one they ship.
2. Shorter
Install cpanm with apt. As root, run "cpanm Switch" and it will install the Switch.pm package and any dependencies. It will also upgrade any already installed packages it thinks it needs to. This last step is why this option isn't ideal. In the (rare) case when the update isn't compatible with something else on your system uninstalling is fiddly.
I tried:
cpan> i /xls2csv/
No objects found of any type for argument /xls2csv/
cpan> install xls2csv
Warning: Cannot install xls2csv, don't know what it is.
Try the command
i /xls2csv/
to find objects with matching identifiers.
I haven't had any problems installing registered modules, e.g.
cpan> install DateTime
It is just the xls2csv that is providing problems.
Thank you for any insights provided.
P.S. Constrained To Windows with ActivePerl 5.10 (I think) Also I have the xls2csv-1.06.tar.gz file downloaded and tried
cpan> install C:/...path to file locally/xls2csv-1.06.tar.gz
That did not seem to work, and I must install locally.
The indexes used by CPAN.pm are all module-oriented, so they don't see distributions that contain no modules. (xls2csv has only a script.) You can still install them by giving the full path (under authors/id) of the distribution, just as you would to install older or development versions of a distribution:
cpan> install K/KE/KEN/xls2csv-1.06.tar.gz
If you are using my cpan(1) command, you can also install whatever is in the current working directory by telling it to install ".".
% cpan .
That should trigger the normal CPAN.pm process for handling dependencies and so on. You should be able to do that in the CPAN.pm shell too.
If you want to fetch the file from a CPAN mirror, you can do it as ysth suggested. You give it the path under authors/id in the repository and CPAN.pm will find it for you. You're skipping the step where it looks in the PAUSE index because you've already given it the path to download.
It's a 5 year old script with few tests (7) none on a Mac, and one bug report (a year old). It appears to not have been updated since it was written so use this script with realistic expectations. In other words, don't be surprised if you can't get it to work.