I can't seem to find anything useful in the man pages etc for this, but it seems like it should be straightforward..?
Our servers are running CentOS 6.8 but also have the Atomic repository for some package versions. The most recent version of one of the packages that Atomic provides seems to be broken, so we've had to do a yum downgrade of that package.
Problem now is that we're running Plesk, which performs automatic Yum updates on a schedule, and the next time this happens, the broken package will just drag back in again!
All I want to do is tell Yum to ignore this specific package version so that it updates the next time there's a newer version, but skips the current.
I found that I can add exclude= lines to yum.conf but I can't seem to find how to define a specific version number in this exclude. It looks like I can only exclude entire package names?
I'm more familiar with Gentoo where we can tell Portage to mask specific versions when problems like this occur. Is this not an option in CentOS?
Much appreciated.
Related
Is there a way to install multiple versions of the same package in CentOS/RHEL (7/8) if the package installs separate files in each version?
We have an application we've recently converted to using RPM instead of a home-built package manager based on tar. In order to make atomic-like switches between versions, each version installed in separate directories with the version number in the name, and a symlink with the unversioned name pointed to the current, or previous, version at any given moment in time. The application, of course, used the unversioned name to get init script, configuration files, interpreter version and code. I'm thinking that the alternatives package would be the basis for this, although we wouldn't use the alternatives command to manage symlinks (although there's no technical reason not to).
Not exactly as you describe.
Some packages allow this (Kernel and Kernel-devel being two of them) but i beilieve this is an exception added within the package manager.
Certain Applications like PHP and Python which is perfectly acceptable to have multiple version (Python2.X and 3.X) do this by changing the base name of the application/rpm.
Take a look at: https://rpm.org/user_doc/multiple_versions.html
It gives a good insight on how to achieve what you want
It is common practice to customize a Yocto made package with an Bit Bake append file _%.bbappend. The problem I am having is even though the package contents have been modified due to the append file, the package keeps the same version number. This is troublesome because dnf install will not install the RPM because it does not think it is an upgrade and a dnf remove before would trigger dependent packages to also be removed. There are ways around this modifying DNF configs, but I get nervous automating those changes in utilities due to the chance of really nasty error states.
Assuming the original package is installed, is there any way to modify the Bit Bake append file so that dnf will install the result like an updated package?
The solution to this is to use the PR service:
https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#working-with-a-pr-service
I believe you want to set (and increment as you update) the PR variable as follows:
PR = "r1"
See: https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#var-PR
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.
After installation of latest Bundle::CPAN, I realized that certain legacy code will not run in this latest version. I wish to remove (and not just unlink) this latest version and revert back to using the old version. How can I do that?
Perl nor CPAN.pm have a way to go back to what you had before you installed later versions of modules. See How can I de-install a Perl module installed via cpan?.
Next time, however, you can fix this problem.
Here's what I recommend:
If you can figure out which modules are causing the problem, install those in separate directories and adjust #INC to use those directories. Do that until you figure out the module versions you need.
When you figure out the distributions you need, grab those from CPAN or BackPAN. Keep the distributions locally and set up your own MiniCPAN with just those distros. Since CPAN has as a design feature to track only the latest versions of any distribution, you want to make your local MiniCPAN pretend that the older distributions are the latest versions. That's why I created MyCPAN::App::DPAN. I write a bit about this in Manage multiple MiniCPANs, and version them
There's also Pinto and Stratopan, which serve like source control for your private CPAN-like repository. Rollback if you get something you don't like.
Once you get things fixed, put your Perl libraries into source control so you can always roll back an installation. See Manage your Perl modules with git.
Come up with an installation and testing policy where you don't disturb anything before you know that everything works. Part of that is testing new installations outside of your main Perl library directories. When you think you're satisfied, then you can install into those directories.
The easiest way is by visiting metacpan.
Search for your module. In your case Bundle::CPAN.
You then have to select the relevant version of the module that you want to install by clicking on the arrow to the left of the module name:
Once you click on the version you want from the drop-down you can then download it or just do for example:
cpanm http://cpan.metacpan.org/authors/id/A/AN/ANDK/Bundle-CPAN-1.861.tar.gz
Hope that helps