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.
Related
I am currently building an autotools-based package for buildroot but I only need some parts of the actual build output (shared libraries and a handful of tools). Is there a way to install only what I need, similar to debian's *.install files when a package should be split up (like a libfoo and libfoo-dev package). If there is no other way, I will have to use the LIBFOO_POST_INSTALL_TARGET_HOOKS but I would like to know if there is a better option.
I know of the LIBFOO_CONFIG_SCRIPTS variable, but this only remove files in the /bin directory and I would like to remove them from other places too (libexec, /var, ...). This method also feels hacky for non-config scripts related to that library.
If there are no autotools configure flags to alter the installation options, one simple method is to patch the Makefile.am as required.
Here are the steps :
Alter the source Makefile.am capturing your changes in a patch(s).
Copy your patches to the global patch directory, they will be applied before building the package.
Remove the package's output/build directory and rebuild it.
At this point, the undesired files will not be installed to the target.
The more detailed method for doing this is to "make package". Go to the package's src. Run quilt to auto-generate patches for you. Alter the sources (Makefile.am), refresh the patches. Copy the patches back to buildroot's global patch directory. Once done, buildroot will patch Makefile.am then it will generate the appropriate Makefiles and will not install as required.
Here is an example :
Assume you have set BR2_GLOBAL_PATCH_DIR="$(BR2_EXTERNAL)/patches"
make package
cd output/build/package
quilt init . # output/build/package/patches now exists
quilt new 001-Makefile.am.do.not.install.patch
quilt add src/Makefile.am
# you edit src/Makefile.am here
quilt refresh # now patches/001-Makefile.am.do.not.install.patch exists
mkdir patch/to/global/patches # see BR2_GLOBAL_PATCH_DIR above
cp patches/*.patch patch/to/global/patches
cd ../../.. # got back to buildroot root to make
rm -rf output/build/package
make package
At this point, your patches should be applied to the src code and the files you removed from the make install process will not be on the target.
Make sure PACKAGE_AUTORECONF = YES in the package.mk file, it forces buildroot to autoreconf.
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.
I have access to the NuGet command-line tool but not to any unzip tools. Is it possible to install a package already saved locally?
After doing a number of searches, I've come up with nothing that handles such a simple requirement. I've also looked at the code but it's far too lengthy/dense to quickly come to a definite conclusion, though, by all indications, it doesn't support the direct install of a local file.
Since it's really just a zip file.
mv ~/path/to/package.nupkg package.zip
This will change the file extension to be a zip file. Then:
unzip package.zip -d ~/Output/dir
If you have the .nupkg stored locally in a directory and all you want to do is extract the files you could use NuGet.exe and do something like:
NuGet.exe install -o extract-directory MyPackageId -source /Full/Path/To/Directory/Containing/NuGet/Package/NuPkgs
The -source parameter allows you to define a new source. In this case the directory where the .nupkg file exists.
The -o parameter defines the directory where you want the NuGet package extracted to.
The above seems to work on the Mac with NuGet 2.12.
I have been trying to work out how to add my own packages as part of a kickstart install (specifically mondo packages) but using the %packages directive as opposed to rpm commands in the post scripts. I tried adding them to the packages file with my %include statement in the kickstart file, and copied the RPM's to the RH linux/Packages directory, however these packages don't get installed. I read something about comps.xml but dont have that file in the RHEL distribution, or know what the procedure is.
Essentially I have a package list which I include like this:
# cat packages.txt
openssh-clients
openssh-server
afio-2.5-1.rhel6.x86_64.rpm
buffer-1.19-4.rhel6.x86_64.rpm
mindi-2.1.7-1.rhel6.x86_64.rpm
mindi-busybox-1.18.5-3.rhel6.x86_64.rpm
mondo-3.0.4-1.rhel6.x86_64.rpm
All the rpms from afio down are custom ones not part of the RH installation.
Could someone tell me how this can be done?
thanks
All kickstart files should have a section near the top where they define available repos. An example repo line would look like this:
repo --name=a-base --baseurl=http://mirror.centos.org/centos/6/os/$basearch
This tells the kickstart system that there is a usable rpm repo at the given url
In order to add your own rpms you need to create a custom repo and point your kickstart files to it by adding a new repo line. Then you can list the core rpm package names in your %packages directive and they will be picked up.
So for you it would be something like:
...
repo --name=a-base --baseurl=http://my.domain.org/customrepo/path/here
%packages
openssh-clients
openssh-server
afio
buffer
mindi
mindi-busybox
mondo
...
I am creating rpm for apc. While writing spec file, I realized that some commands may have path which can keep on changing which are required during the compilation time. For eg. these commands are required to be executed during the building time.
$ /usr/local/php/bin/phpize
$ ./configure --with-php-config=/usr/local/php/bin/php-config
But the complete path of phpize and php-config file may change. So how can i prevent this dependencies so that i should not hard-code these path in my spec file.
Because these commands are used at building time, the ideal solution to this problem is here:
Find packages on distribution which provide these commands or paths e.g php-config is provided by php-devel package on Fedora operating system. In fedora you can find it using yum whatprovides "*/php-config" or if they are already installed on system then using rpm -qf /path/to/command.
Once you know the packages add them as BuildRequire tag in spec file. Step 2 will make sure that paths are always present whenever you build the package from spec file even if you use hard coded paths (which isn't ofcourse best way to do it).
In place of /usr/ you can use %{_prefix}, it depends entirely on macros available on distribution you are building this rpm on. Check macro files for path macros. One link which has common macro definitions is here.