I am new to packaging.
This website states that the steps during an upgrade are:
Hence, the order of operations during an upgrade is:
Run the %pre section of the RPM being installed.
Install the files that the RPM provides.
Run the %post section of the RPM.
Run the %preun of the old package.
Delete any old files not overwritten by the newer version. (This step deletes files that the new package does not require.)
Run the %postun hook of the old package.
Regarding step 5, how exactly does it determine which files it should delete? Does it only delete files that are part of the %install/%post step of the old version? Or would any files in the install dir (if the concept of "the install dir" even makes sense) that is not part of the new version's %install/%post get deleted?
The files listed in the %files section. That's why they're needed to be explicitly given.
You didn't mention that if they are tagged %config they won't be overwritten.
RPM will compare list of %files section. If old package has some file listed in %files and a new package does not have it, then it is deleted. If both packages have it listed then rpm will not delete it.
Related
I have 2 RPM files. In RPM1 I have for example File.xml. In RPM2 this file is not present, but I create it via some scripts. As I know, after Upgrade, if the file is not in the list of RPM2 it will be deleted. Is there any configurations in the Spec file not to delete this file?
The easiest solution is to create a dummy file in the RPM2. But I would like to use SPEC file.
if the file is not in the list of RPM2 it will be deleted
no. The list of files are the files that the rpm detains. If you remove the rpm, then those files will be removed. Custom files that you create in %post scripts for example will not be removed, because rpm doesn't know who they belong to.
Example part of a spec file:
%post
echo "content" > /etc/file.xml
%files
/etc/file2.xml
when you install the rpm created with above spec file; /etc/file.xml and /etc/file2.xml will be present on the system.
If you now remove that rpm, /etc/file2.xml will be removed (because in the %files section), but /etc/file.xml will remain because it does not belong to your rpm.
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
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.
VS 2013 fails to restore a package - the package contents are not materialized - although VS/nuget appears to think that it did restore the package successfully.
If I manually uninstall and re-install the same version of that package, it works as it should.
A bare-bones repro can be downloaded as a zip. This repro has a
single solution with a
single project with a
single file, "packages.config", specifying a
single package, "breeze.edmbuilder -version 1.0.4", containing a single file, edmbuilder.cs
single folder, "App_Start", contains nothing but
the .csproj says it should have "edmbuilder.cs" which is ok because
it WILL have "edmbuilder.cs" when the package is restored.
When I build, VS reports that "edmbuilder.cs" is missing ... and indeed it is missing.
However, the package was downloaded; I know this because the build produces a "packages" folder that contains "Breeze.EdmBuilder.1.0.4" wherein I see that "edmbuilder.cs" is present and in the right place.
When I issue the command install-package breeze.edmbuilder -version 1.0.4, nuget reports
'Breeze.EdmBuilder 1.0.4' already installed. NugetRestoreFail already has a reference to 'Breeze.EdmBuilder 1.0.4'.
There is nothing wrong with this package AFAIK. For when I uninstall-package breeze.edmbuilder and then reinstall with install-package breeze.edmbuilder -version 1.0.4, the install works and the missing edmbuilder.cs appears in the "App_Start" folder where it belongs.
The failure is repeatable in place.
close the solution
delete edmbuilder.cs from "App_Start"
delete the "packages" folder
optionally delete the .suo and bin and obj directories
re-open the solution and re-build
You'll get the same failing behavior ... and the same ability to manually uninstall and reinstall.
FWIW, removing the reference to edmbuilder.cs from the .csproj has no effect.
No matter what I do, I have to manually uninstall and re-install the package.
WTF!
p.s.: I am using VS 2013 Update 2 RC. I doubt that the "RC" matters as this problem came to my attention from a customer. You never know.
p.p.s: This is not about the build failing and I don't care that this solution would never run. What you see here is a stripped down version of a real app that would have worked. The only question is "why no restored file?"
Package Restore is NOT the same as installing a package. What you are seeing is by design. It simply downloads any missing packages in the packages folder. No more. No less.
Package Restore was added so you wouldn't need to commit the packages folder to source control.
It is expected that you would install a package then commit the changes made to your project files as well as any files that may have been added like your edmbuilder.cs, essentially anything inside your project folder. You would exclude the packages folder.
Now when you get the source from source control everything would be present except for the package files. Package Restore would download those and now your working copy is complete.
See NuGet's Restore Package insists on specific package versions
Is this stupid or what?
Thanks to #Kiliman for explaining that my horrible experience is "by design".
So how do you actually get the content you thought was being restored? Do you install each package one at a time. That's insane.
I was going to observe that there is no nuget equivalent of an npm install that would fetch all the packages you need ... when I discovered that there actually IS an almost-equivalent. It's just not obvious and I wonder how many people know it exists.
It's a two step process:
FIRST restore the missing packages ... THEN
Issue the command: Update-Package -Reinstall
This re-installs all packages in every project in your solution.
If you only want to re-install for a specific project, try:
Update-Package -ProjectName 'YourProjectName' -Reinstall
In both procedures, the -Reinstall switch strives to install the exact versions of the packages spelled out in your package.config ... and not newer "updated" packages which may or may not work for your project (but see the documentation for exceptions).
Read about update-package -reinstall in the official nuget documentation entitled, "Reinstalling Packages and its Pitfalls".
Do not miss the cautionary remarks. Clearly this technique is but an approximation of what you'd expect from other package managers.
Good luck, peoples.
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