Let's say your spec file is synced to upstream v1.0.0 and that changes to v2.0.0, what should the changelog entry say that rebuilds the package from the latest upstream source? [From the docs](https://rpm-packaging-guide.github.io/) > The last section, %changelog is a list of date-stamped entries that correlate to a specific Version-Release of the package. **This is not meant to be a log of what changed in the software from release to release, but specifically to packaging changes.** For example, if software in a package needed patching or there was a change needed in the build procedure listed in the %build section that information would go here. That example is one where the change in patching or in the RPM spec, but what do you put in the specfile if you're just rebuilding from a new upstream? What if you're packaging your own software and the specfile is generated from your repository, or exists in your repo.

In some RPM specfiles, I see lines like: BuildRequires: pkgconfig(ice) BuildRequires: pkgconfig(libnotify) BuildRequires: pkgconfig(libssl) ... I am not very familiar with pkgconfig but I understand that some installed libraries have a corresponding .pc file which describes them. I have 2 questions: 1. Is this only used for dynamic libraries? 2. How does RPM handle the above in a situation where ice, libnotify, and libssl are NOT found on the system currently or where they are found but there is no corresponding .pc file?

I am fairly new to rpm building and i have been trying to understand the syntax of "Provides" inside a spec file without success. I have the following spec file snippet for building clamav rpm: Summary: End-user tools for the Clam Antivirus scanner Name: clamav Version: 0.103.12 Release: 1%{?dist} %package data Summary: Virus signature data for the Clam Antivirus scanner Requires: ns-clamav-filesystem = %{version}-%{release} Provides: data(clamav) = full Provides: clamav-db = %{version}-%{release} Obsoletes: clamav-db ` # rpm -q --requires RPMS/x86_64/ns-clamd-0.103.12-1.el8.x86_64.rpm /bin/sh /bin/sh /bin/sh /bin/sh coreutils data(clamav) # rpm -q RPMS/noarch/ns-clamav-data-0.103.12-1.el8.noarch.rpm --provides clamav-db = 0.103.12-1.el8 config(ns-clamav-data) = 0.103.12-1.el8 data(clamav) = full ns-clamav-data = 0.103.12-1.el8

I am new to rpm building and for the past week I am trying to code a spec file to install a file on the system only if a specific files is missing. Here is a snippet %global homedir %{_var}/lib/test Source10: main.db Source11: back.db %files data %defattr(-,%{updateuser},%{updateuser},-) %config(noreplace) %verify(not size md5 mtime) %{homedir}/*.db I would like to add a condition where, If file /var/lib/test/file1.txt is missing, install /var/lib/test/back.db I am aware I need to use the %files macro but so far I am not able to figure out how to write the if condition

Let's say I have two packages and a library, all at version 1. * PackageFoo version 1. * PackageBar version 1. * LibBaz version 1. Now, * PackageFoo requires LibBaz * PackageBar requires LibBaz However, let's say at some point LibBaz introduces a BREAKING CHANGE... let's call it Version 2.0. This change is such that we know all prior dependencies on LibBaz version 1.0 will need to be updated. * PackageFoo version 2.0 is shipped concurrently to use the newer version of LibBaz version 2.0 * but, LibBaz version 1.0 is known to conflict with PackageFoo prior to version 2. How do we ensure installing a newer version of LibBaz (version 2.0) will FORCE an update on PackageFoo (ideally all packages that depend on LibBaz version 1) or prevent the update to LibBaz? ---- _The library in this question can not be installed alongside another version of the same library, unlike in C._

On a Fedora System, I'm often recompiling the kernel in order to add the necessary T2 patches for the kernel to benefit from the full capabilities of my MacBook Pro (and also so that the keyboard works with the apple-bce drivers). It happens though that, when I recreate the kernel package RPMs using the original SRPM from the Fedora repository, no matter when I compile the kernel, the installed vmlinuz file that goes into /boot has always the same date/time for each release (independent of the compilation date/time). This happens even for my custom kernel (in which I just stuff the patches inside linux-kernel-test.patch before compiling). The problem with this is that I endup having multiple vmlinuz... images on /boot with the exact same date/time, which confuses refind (the boot loader I use) on what image to load. Of course I workaround this by running touch after installing the custom Kernel rpms, but I'd like to know where is this date/time configured. I could not determine this by doing a quick visual inspection of the .spec file and of the the source code, and I'd really appreciate if a good soul could indicate me the spot and file. Note: I understand the date is artificially set so that the generated kernels have uniform properties for the same version and patch level, which is good for testing purposes, but this is not clear for me if this artificial date/time is a distribution independent kernel attribute or a Fedora package attribute.

I have a spec (myspecfile.spec) file that looks similar to Name: package-%{myname} Version: %{myversion} Release: %{myrelease} License: gpl2 Summary: this is my package BuildArch: noarch %description Some description of the package %files %changelog I run rpmbuild like: rpmbuild -bb new.spec --define 'myname my_name' --define 'myversion my_version' --define 'myrelease my_release' --define 'myprovide my_provide' And /home/user/rpmbuild/RPMS/noarch/package-my_name-my_version-my_release.noarch.rpm is created. All well and good, but is there any way to give one of my variables a default value? If I omit one of them? Say, I run rpmbuild -bb myfile.spec How can I get those variables listed to contain a default value? If I do a %define myname my_name it will always contain this value no matter what I pass in via the command line.

I'm trying to understand how the creation of packages (rpm, deb, dpkg) work and what the architecture supports and doesn't. Right now I struggle figuring out what happens when the installation or upgrade of a package fails at different points of the process -ie, error on a scriptlet, not enough disk space (is this checked before starting?)-. From my current understanding, there's no automatic rollback to a previous working version if there was any. So my question would be, how do packages deal with this scenarios? Aren't scriptlets used at all to backup files and restore them post transaction if some error occurred? (I coudln't find examples so far) Thank you.

I am trying to build a RPM from a python application on RHEL8.2 machine. the shebang on the scripts are set correctly to #!/usr/bin/python3 however for some reason the shebang gets changed to #!/usr/libexec/platform-python -s when the RPM is built. I have tried almost everything. I have undefined the mangling according to doc: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/packaging_and_distributing_software/advanced-topics %undefine __brp_mangle_shebangs but the shebangs gets still changed. this is the relevant parts of the specs file: %undefine __brp_mangle_shebangs Name: myapp Version: 2.0.0 Release: 1%{?dist} summary: rpm for my APP BuildArch: noarch ### Build Dependencies ### BuildRequires: python3-setuptools BuildRequires: python3-devel %?python_enable_dependency_generator %build %py3_build %install %py3_install %files .... I can include python*-rpm-macros to the specs and that would set the shebang to something like /usr/bin/python3.6 but it is too restrictive. Our code works in anything > python3.6 so if we deploy the rpm in a system with python3.8 it should work. how can I set /usr/bin/python3 or leave the shebang unchanged on the python scripts? when the rpm is packaged?

I want to package a python application which can run on both python2 and python3 for we have still old systems running python2. the default should be python3 but in case of python3 is not installed. I would like to build it for python2. without changing the name: i have followed the instruction here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_conditionalizing_the_python_2_parts and I tried this: %global srcname example # Disable python2 by default %bcond_with python2 Name: python-%{srcname} Version: 1.2.3 Release: 1%{?dist} Summary: An example python module License: MIT URL: https://pypi.python.org/pypi/%{srcname} Source0: %pypi_source BuildArch: noarch %global _description %{expand: A python module which provides a convenient example.} %description %_description %if %{with python2} %package -n python2-%{srcname} Summary: %{summary} BuildRequires: python2-devel %description -n python2-%{srcname} %_description %endif %package -n python3-%{srcname} Summary: %{summary} BuildRequires: python3-devel %description -n python3-%{srcname} %_description %prep %autosetup -n %{srcname}-%{version} %build %if %{with python2} %py2_build %endif %py3_build %install # Must do the python2 install first because the scripts in /usr/bin are # overwritten with every setup.py install, and in general we want the # python3 version to be the default. %if %{with python2} %py2_install %endif %py3_install %check %if %{with python2} %{python2} setup.py test %endif %{python3} setup.py test %if %{with python2} %files -n python2-%{srcname} %license COPYING %doc README.rst %{python2_sitelib}/%{srcname}/ %{python2_sitelib}/%{srcname}-*.egg-info/ %endif %files -n python3-%{srcname} %license COPYING %doc README.rst %{python3_sitelib}/%{srcname}/ %{python3_sitelib}/%{srcname}-*.egg-info/ %{_bindir}/sample-exec %changelog but It always tries to build both which fails furthermore i need to change the package name eg python2-%{srcname}. I need them to have the same names it is not a python module it is a standalone program.

I'm writing a RPM spec file for building my software. The software depends on [Crypto++](http://cryptopp.com) . Crypto++ is named differently on different distributions, for example, on OpenSUSE, I should write

BuildRequires: libcryptopp-devel

But on Fedora, it should be

BuildRequires: cryptopp-devel

Now, how can I unify the two in a single spec file?

I'm using aws's ec2 instance and I need to install a newer version of GDB (I can't use yum install since there is no newer version available for amazon RHEL). My workflow requires to do this process often and I thought of having a prepared RPM to implement this task. I'm new to the process of creating RPMs and I'm not sure how to do it, I started to write the file but I ran into some issues, I'd like to share with you the file, with the issues I got: 1. I'd like to get some insight and understand if there's a better way of writing the spec file. 2. Currently I'm getting errors since I need to use the pkg's "configure" before, but this requires creating a "build" directory and only run make from within that directory. Currently I solved this by make from within a directory I created within the BUILD/gdb-9.1 dir. But I'm sure there's a more idiomatic way of doing it. 3. for this process to work, I first need to install gcc-c++ and expat-devel. I what is the best way to do it, currently my option are: 1. put it as part of the rpm installation. 2. run this command prior to the rpm installation. (yet I'd like the rpm to be something that it's the only this required, but I'm not sure if it's a good idea)

%define gdb_version       9.1
%define gdb_release       1

Name: gdb
Summary: GNU Debugger
Version: %{gdb_version}
Release: %{gdb_release}
License: GPL
URL: http://www.gnu.org/software/gdb/ 
Source0: gdb-%{gdb_version}.tar.gz
BuildRequires: readline-devel, ncurses-devel

%description
GDB, the GNU Project debugger, allows you to see what is going on inside another program while it executes.

%prep
%autosetup

%build
mkdir build
cd build
../configure \
--host=x86_64-redhat-linux-gnu \
--target=x86_64-redhat-linux-gnu \
--with-auto-load-dir=$debugdir:$datadir/auto-load:/usr/share/gdb/auto-load \
--with-auto-load-safe-path=$debugdir:$datadir/auto-load:/usr/share/gdb/auto-load \
--with-expat \
--with-gdb-datadir=/usr/share/gdb \
--with-jit-reader-dir=/usr/lib64/gdb \
--without-libunwind-ia64 \
--with-python=/usr \
--without-guile \
--with-separate-debug-dir=/usr/lib/debug \
--with-system-gdbinit=/etc/gdbinit \
--without-babeltrace
make %{?_smp_mflags}

%install
cd build
make install

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)

How is best to handle files in an rpm spec file that may or may not exist with these specifics: Part of the files delivered are example files under a /conf.d/ directory. The files are installed as conf.d/example.conf-. It is expected that the user would copy or rename the files with the end hyphen removed so the application will use it. The application uses /conf.d/*.conf as is common. All files with and without a hyphen suffix should be part of the package with permissions managed by the rpm. The original hyphen-suffixed files may or may not exist at update or remove time. Same with the non hyphen-suffixed versions. It appears that both file name versions must be added to buildroot but I'm not sure of best practice to name some as ghost. The user may also add a conf file of their own. Is it possible to enforce permissions for files in a package owned directory but not known to the package? The conf.d/*conf strategy is commonly used but I haven't found any example of handling this other than ignoring user created files and not deleting the directory on remove if any exist. Advice, references and/or examples would be appreciated.

I'd would like to transition an existing *.spec file from the fedora style %cmake* commands to the alternate %cmake3 based one (eg. Amazon Linux 2). What should I replace an existing %cmake_build with ? Minimal reproducible example: % cat Dockerfile FROM public.ecr.aws/lambda/dotnet:7 WORKDIR /tmp RUN curl -O https://kojipkgs.fedoraproject.org//packages/dcmtk/3.6.7/3.fc39/src/dcmtk-3.6.7-3.fc39.src.rpm RUN yum -y update && yum -y install rpm-build make gcc-c++ cmake3 libjpeg-devel \ libpng-devel libtiff-devel libxml2-devel openssl-devel zlib-devel doxygen \ git-core RUN rpm -i dcmtk-3.6.7-3.fc39.src.rpm WORKDIR /root/rpmbuild/SPECS/ RUN sed -e '/0017-Increase-sleep-for-tests.patch/ s/^#*/#/' -i dcmtk.spec RUN sed -e 's/BuildRequires: cmake/BuildRequires: cmake3/g' -i dcmtk.spec RUN sed -e 's/%cmake /%cmake3 /g' -i dcmtk.spec RUN rpmbuild -ba dcmtk.spec Gives: % docker build . [...] -- Build files have been written to: /root/rpmbuild/BUILD/dcmtk-3.6.7 + %cmake_build /var/tmp/rpm-tmp.p5JL4r: line 70: fg: no job control error: Bad exit status from /var/tmp/rpm-tmp.p5JL4r (%build) And I do not see any cmake3_build command in: # grep build /usr/lib/rpm/macros.d/macros.cmake3

When writing a .spec file for Fedora, I ran into a problem. I can't seem to be able to do fedpkg mockbuild at all. No matter what source I use, HTTPS or local, I keep running into this error:

Failed to get repository name from Git url or pushurl
Failed to get ns from Git url or pushurl
Could not execute mockbuild: ('Could not download sources: %s', AttributeError("'NoneType' object has no attribute 'head'"))

What's going on? The relevant part of my .spec file:

Name:           purple-telegram-tdlib
# The main maintainer has not merged #154 for TDLib 1.8.0
Version:        0.8.1-BenWiederhake
Release:        1%{?dist}
Summary:        New libpurple plugin for Telegram

License:        GPLv2
URL:            https://github.com/ars3niy/tdlib-purple 
Source0:        tdlib-purple-BenWiederhake-master.zip

BuildRequires:  gcc-c++
BuildRequires:  git
BuildRequires:  make
BuildRequires:  cmake
BuildRequires:  tdlib-devel == 1.8.0
BuildRequires:  tdlib-static == 1.8.0
BuildRequires:	libpurple-devel
BuildRequires:	libwebp-devel
BuildRequires:	libpng-devel
BuildRequires:	gettext-devel

I am trying to compile & package the latest version of Zeek (5.0.7) for rhel 7 servers. I get an error saying the "cxx17" is required. Searching the web, I found that it is contained in devtoolset-7 which I downloaded. However, I can't find anything telling me what I have to put in the spec file for it to be used.

What's the right way to create an RPM that modifies the %config(noreplace) files installed by another RPM? Specific instance of the general question: We want to modify the repository definitions installed by almalinux-repos so that the definitions have a baseurl pointing to our internal mirror. Because the repository definitions are %config(noreplace) in almalinux-repos, we could modify them any number of ways. However, we'd like to have our modifications packaged as well. One idea is to create a new package that Obsoletes: almalinux-repos. This would suggest using almalinux-repos as a BuildRequires and then including its files in the buildroot. It's so easy for Obsoletes to go bad that we are averse to this approach. Another idea is to create a new package that Requires: almalinux-repos and then uses %patch to modify its files. Secondary question: Assuming we use the %patch mechanism, should we add Supplements: almalinux-repos to our new package so that it is automatically included in package resolution?

After reading https://unix.stackexchange.com/a/222376/246754 How rpm ensure that no uid/gid clash with each other ? What I am looking is similar to https://github.com/NixOS/nixpkgs/blob/68196a61c26748d3e53a6803de3d2f8c69f27831/nixos/modules/config/users-groups.nix#L640-L642 (given for comparison) I have though to building a VM and take the /etc/passwd to see taken uid. It doesn't fully anser my need because 174 is not their by default. Again nix also reserve some uid like 0 for root https://github.com/NixOS/nixpkgs/commit/dba1d48b7897c49e5df9430c6b60f17e03ec361e and I can see the list without building a VM or can query with the cli. They also have an allocator for id so I don't have to manage it. This is a scriptlet run when rebuilding /etc/passwd PS: I have tagged rpm-spec because the linked question is about RPM but the problem is more likely to happen to other tools like apt, yum, pacman, brew... If you have knowledge for other system please create another question and answer it (to keep Q&A style) or comment

I have an RPM that runs a scriptlet to add a user and create a home directory. I have used this before on CentOS 7, but now need this RPM to run it on Rocky Linux 8 so I've rebuilt the RPM (it's noarch but needed other changes), but run into this issue when installing the RPM on Rocky 8 when it comes to adding the user, that I did not come across on CentOS 7: useradd: cannot create directory /opt/system-installer The script does some checks adds a group if necessary but essentially runs the command: useradd --system --gid usergroup --home-dir /opt/app-user --shell /sbin/nologin app-user --create-home --comment "App Management User" If I run the command in the terminal there is no problem, but whenever I install the RPM the user home directory is not created and I run into issues with the user. I have tried altering the scriptlet to make the directory before running the useradd command but because the directory is already there it doesn't copy over the .bash* files either. I have also tried adduser as an alternative but have the same issue, it can't create the home directory. What about running the command as part of an RPM scriptlet could be different to running the command via the commandline or a bash script (which I have also tried without issue")? All are run as root. One thought I have as a temporary measure is to run a command to copy over the files from /etc/skel but that doesn't quite seem right to me.

I have a .spec file to install a rpm. I have the following snippet in post install (%post scriplet)

%post -n %{package_name}
# Enable the service at boot time
%if %{?suse_version:1}0
  /usr/lib/lsb/install_initd %{_initrddir}/%{package_name}
%else
  chkconfig --add %{package_name}
%endi

During zypper install package_name it fails at the post installation phase with the following error:

/var/tmp/rpm-tmp.Z5R29N: line 2: /usr/lib/1sb/install _initd: No such file or directory
warning: %post (package_name.sles15.x86_64) scriptlet failed, exit status 127

I am a novice in .spec files for rpm but this scriplet failed because /usr/lib/lsb/ directory doesn't exists in SLES 15 SP4 My Questions are: 1. What is this scriplet exactly doing? 2. Where to get this /lsb/ package from so that I can create this path in SLES 15 SP4? I check that SLES 15 SP4 pre-installed with lsb-xxx package but they are not working here ? 3. Do I need to do case checks here for sles 15 SP4 inside this scriplet? like:

%if 0%{?sle_version} == 150400 && 0%{?is_opensuse}
// do somthing
%endif