If I build my own RPMs, is there a way, to tell that before upgrade to the latest version, upgrade to a specific other version first?
So for example I often made a mistake in my postun actions, that I delete a link. So when I want to update to an newer package that fixes my postun action, the usually RPM behavior is that my new packages will be installed, then the old package will be uninstalled and trigger my mistake in the postun action. So I would need to run a reinstall then or to update again to an even later version, that on the next update, my postun action is correct.
So I would imaging something like
UpdateRequires: MyPackage >= 1.1
There is no way to force an update chain like that. You could have the user reinstall the new package. Another option is to fix the symlinks in your %verify stanza and tell the user to run rpm -V on your RPMs.
It is possible to run a step after old packages %postun with %posttrans in new package
Related
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 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.
I'm unfortunately not very experienced in CentOS administration, and was hoping someone might be able to help me understand and get past a small hurdle. I was hoping to run yum update on the system, but ran into some Transaction Check Errors:
file /etc/php.ini from install of php55-common-5.5.11-1.el6.x86_64 conflicts with file from package php-common-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/curl.so from install of php55-common-5.5.11-1.el6.x86_64 conflicts with file from package php-common-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/fileinfo.so from install of php55-common-5.5.11-1.el6.x86_64 conflicts with file from package php-common-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/phar.so from install of php55-common-5.5.11-1.el6.x86_64 conflicts with file from package php-common-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/pdo.so from install of php55-pdo-5.5.11-1.el6.x86_64 conflicts with file from package php-pdo-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/pdo_sqlite.so from install of php55-pdo-5.5.11-1.el6.x86_64 conflicts with file from package php-pdo-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/sqlite3.so from install of php55-pdo-5.5.11-1.el6.x86_64 conflicts with file from package php-pdo-5.3.3-40.el6_6.x86_64
It sort of looks like it's saying that some newer version files are conflicting with older version files. Is there a standard way to fix this? I was mainly just trying to update so that I could install Java later, but wasn't expecting to run into these errors. If it helps, the server is mainly being used for hosting a few websites with apache and mysql. Thanks so much for any help, it's greatly appreciated.
Edit: To add some more clarification, I had previously edited the baseurl variable in the /etc/yum.repos.d/centalt.repo file, which was originally set to
baseurl=centos.alt.ru/repository/centos/6/$basearch
The reason I changed the location was because I was previously getting an error when trying to run yum update, mentioned in this other stackoverflow question https://unix.stackexchange.com/questions/132674/repository-metadata-repomd-xml-for-repository-mratwork-centalt which had an answer recommending replacing the URL with
baseurl=mirror.sysadminguide.net/centalt/repository/centos/6/$basearch
Is there a different url I should be using instead?
You have a non-official repository which provides the php55-* packages which conflict with the official php-* packages.
You currently have the php-* versions installed.
If you want to switch you can try manually installing the matching php55-* package for every php-* package you have installed in one yum command (though that may not work).
If it doesn't, you might need to remove all the php packages you have installed first and then install the php55 versions after that.
I have an install.ps1 script in my NuGet package. This script runs both during a new install (after all the files have been copied) and during an upgrade.
I want to show a Getting Started page during a new install, but for an upgrade I want to show the Release Notes.
I found this great answer that tells how to open a URL and it works great. But I am stumped on trying to tell the difference between a new install and an upgrade.
The best solution I have come up with so far is to add a Release Notes link to the top of the Getting Started page, but that is something that could easily be missed by upgraders, and is an unwanted distraction for new installers.
I don't think it's possible to know if the current operation is install or upgrade. When NuGet upgrades a package, what NuGet does is basically uninstall the existing package and install the new package.
I suppose you could do something with install.ps1 that "dirties" the project in some way on the first install, which you will not clean up with uninstall.ps1. Maybe insert a dummy file into the project (outside of the normal NuGet handling, so the file won't get uninstalled automatically) or add some other dummy element to the project file. Then, when you see those "leftovers" from a previous install (which were purposely not cleanly uninstalled), you will know that you are installing an upgrade.
I have currently installed a version of rpm (x.rpm) that needs to be renamed in the next version (y.rpm). To accomplish this, I decided to obsolete the old (x.rpm) rpm. When I run the rpm –Uvh y.rpm on the new rpm here are the steps that takes place:
-Pre-transaction
-Pre-install
-Post install
-Pre uninstall
-Post uninstall
However, my post-uninstall script has some clean up steps that goes and does an rm –rf for some folders. The post-uninstall for both version of the rpm is exactly the same so now, when I installed the new rpm (y.rpm), some folders that were required by the new version gets removed because of the post-uninstall script.
How do I get around this issue?
Any help is greatly appreciated.
Thank you.
Here is what i would do:
create a newer version of x.rpm with changed post uninstall script that doesn't remove folders
update x.rpm on all machines
wait for a while (depending if this is an in-house project or an open project on the internet)
start deploying y.rpm