How to create a Patch RPM?

English Programming/Scripting
1

Hello folks,

I would like to be able to create a patch RPM as hinted at in section 6.2.3 of the SLES guide here: https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_rpm.html.

As far as I can see this is a binary patch rather than a source code patch of an SRPM but i can find no information on how to actually create such an RPM. We are curently producing delta RPMS using the makedeltarpm command but want a way to update an existing installation without the need to reinstall in a production environment.

Can anyone point me in the right direction of how to create these patch RPM files.

Thanks.

2

Well, the page you link to states that more information is to be found in the man pages of rpm or rpmbuild, but those do not even mention the work “patch” here.
And trying the commands listed there (“rpm -qp xxx” e.g.) just results in an error message “unknown option”.

So it looks to me that this is either a SLE specific feature, or it has been removed meanwhile (SLE11 is quite old compared to current openSUSE releases).

But what’s the problem with delta rpms?
There’s no need to “reinstall” the system, only the updated packages.

Even the SUSE documentation states:

NOTE: Official Updates for SUSE Linux Enterprise Server

In order to make the download size of updates as small as possible, official updates for SUSE Linux Enterprise Server are not provided as Patch RPMs, but as Delta RPM packages. For details, see Section 6.2.4, Delta RPM Packages.

3

Thanks wolfi323,

I drew a blank with searches around patch RPMs and the man pages mentioned hence the topic. Yes SLES 11 SP3 is old but that is what the customer uses in their environment and so is what we need to support and unfortunately they are not comfortable with reinstalling the whole package versus what has actually changed.

4

Well, for SLE related questions you’re probably better off in the SUSE forums:
http://forums.suse.com/ (you should be able to login with the same username/password as here)

You would need SLE11 then to actually create those patch rpms, I suppose.

Sorry, can’t help you more, i don’t find any information about those “patch rpms” either, other than that they don’t seem to exist…

5

Thanks, I’ll have a look over there and see if I can find somewhere appropriate to post.

6

On 2015-08-03 15:36, wolfi323 wrote:
> Sorry, can’t help you more, i don’t find any information about those
> “patch rpms” either, other than that they don’t seem to exist…

In openSUSE, patches are FULL rpms, which is why they are not
documented. It is simply what we apply with “zypper patch”.

A delta rpm contains just the differences between a previous rpm and the
current one. The download is smaller, but at the local machine the delta
is applied against the original rpm, creating the same FULL patch rpm,
the same as if you had downloaded it directly. At a second step, the rpm
command installs that locally created patch rpm, not the delta.

With fast internet, it is often faster to ignore deltas:


/etc/zypp/zypp.conf

download.use_deltarpm = false

Thus in both cases, delta or patch, the rpm command applies a full
package update. That’s how it works.

Of course, the rpm might, or might not, compare the current installed
files with what is contained in the patch, and decide not to touch
unchanged files. Or not. This is a detail I don’t know. A test would
find out.

So I guess the client is misguided.

Or I’m wrong, and SLES works differently — after all, this is not a SLES
forum so I have no reason to know :wink: :stuck_out_tongue:

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

7

No, it doesn’t.
The full package is installed, all files are replaced whether they changed or not. A special case are config files though, depending on the package they might be replaced by the new version (storing the previous one in a xxx.rpmsave file) or not (installing the new version in an xxx.rpmnew file), but only if they have been modified in the installed system.

If a file is not modified by the update, it doesn’t matter much anyway whether it is replaced by the new one or not though, I’d say.

Or I’m wrong, and SLES works differently — after all, this is not a SLES
forum so I have no reason to know :wink: :stuck_out_tongue:

Well, the SLE11 documentation (see the link in the first post) does indicate that there are patch RPMs there, i.e. RPMs that only patch the changed files in the system.

8

On 2015-08-03 16:26, wolfi323 wrote:

> If a file is not modified by the update, it doesn’t matter much anyway
> whether it is replaced by the new one or not though, I’d say.

Well, it has some implication: a “zypper ps” detects the in use previous
files, so that we restart the affected services or applications. If the
new file is in fact the same, we waste time, and possibly, downtime.

>> Or I’m wrong, and SLES works differently — after all, this is not a SLES
>> forum so I have no reason to know :wink: :stuck_out_tongue:
>>
> Well, the SLE11 documentation (see the link in the first post) does
> indicate that there are patch RPMs there, i.e. RPMs that only patch the
> changed files in the system.

Ah. Interesting. So SLES is different.
I wonder how they are created :-?

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

9

Ah, true. Didn’t think of that.

Although the question is how relevant this really is in practice.
If a service/application uses a file from an rpm package, it probably uses others from the same package as well (directly or indirectly), so probably would need to be restarted anyway.

Ah. Interesting. So SLES is different.
I wonder how they are created :-?

Yes, that’s the original question in this thread.

I have no idea, probably rpmbuild has a specific command line option for that (apparently rpm itself does have additional options to deal with patches), or there’s a specific command included to create a patch rpm out of two normal rpms. Or something like that.

10

I can confirm that the files in a package are overwritten when the reconstructed full RPM from the delta is applied (apart from those marked as configuration files in the spec file) although I found out some of this the hard way :). The reason we use deltas is because the production environment is extremely bandwidth limited making sending full RPMs down unfeasable on a regular basis. I actually have OpenSUSE installed at home (moved there from Mandriva via Kubuntu whilst looking for another good KDE distro) and wasn’t aware of such differences between it and SLES but good to know.

Thanks.

11

On 2015-08-03 18:16, wolfi323 wrote:
>
> robin_listas;2722299 Wrote:
>> Well, it has some implication: a “zypper ps” detects the in use
>> previous
>> files, so that we restart the affected services or applications. If the
>> new file is in fact the same, we waste time, and possibly, downtime.
> Ah, true. Didn’t think of that.
>
> Although the question is how relevant this really is in practice.
> If a service/application uses a file from an rpm package, it probably
> uses others from the same package as well (directly or indirectly), so
> probably would need to be restarted anyway.

Yes, true.

Unless… unless it is a data file and the service is clever enough to
reload it. Or it is a binary that is often started, till it does the
processing and exits: you don’t have to bother restarting it, it will be
started again for the next job without disruption.

So it would depend on what exactly is updated. This is a very fine
grained distinction, I might see SLES doing it, but not openSUSE.

>> Ah. Interesting. So SLES is different.
>> I wonder how they are created :-?
>>
> Yes, that’s the original question in this thread.
>
> I have no idea, probably rpmbuild has a specific command line option for
> that (apparently rpm itself does have additional options to deal with
> patches), or there’s a specific command included to create a patch rpm
> out of two normal rpms. Or something like that.

Probably.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

12

But in those cases it doesn’t matter if unchanged files are overwritten or not.
The services will just “automatically” use the new files anyway, no need to restart them.

So it would depend on what exactly is updated. This is a very fine
grained distinction, I might see SLES doing it, but not openSUSE.

I just had a look at an old openSUSE “rpm” package (11.1), and the man page in that package does mention those options related to patches, e.g.:

PACKAGE SELECTION OPTIONS:

PACKAGE_NAME

Query installed package named PACKAGE_NAME.
…
-P, –patches
Limit the selected packages to patch-rpms. As a side effect, limit the file list to patched files.
…

I don’t find anything in the old “rpmbuild” man page though, but in openSUSE 11.1 there is also a package called “patchrpm” with a command “makepatchrpm”.
That’s the man page, and the answer to the question: :wink:

**MAKEPATCHRPM
**
Section: Maintenance Commands (8)

NAME

makepatchrpm - create a patchrpm from a number of rpms

SYNOPSIS

makedeltarpm -b] -s] oldrpm1 oldrpm2 … oldrpmN newrpm patchrpm

DESCRIPTION

makepatchrpm creates a patch rpm from a set of old rpms and a new rpm. The created patch rpm can be used to upgrade a system that has either one of oldrpm1, oldrpm2… oldrpmN installed to newrpm.

The old rpms can either be full rpms or just “rpmlist” files containing the filelist. See the rpmgetlist(8) command for how to create a rpmlist file.

There are two options for creating patch rpms suitable for older systems: the -b option makes makepatchrpm use an obsolete value for the file flags, use it when creating patch rpms for SuSE-8.0 systems.

The other option, -s, tells makepatchrpm not to add a SHA1 signature header to the patch rpm. It must be used for all systems older than and including SuSE Linux 10.0 (this includes SLES9 but not SLES10).

SEE ALSO

rpmgetlist(8)

AUTHOR

Michael Schroeder <mls@suse.de>

(the “makedeltarpm” in the synopsis is indeed in the original man page, that’s no mistake by me…)

So it seems that feature has been removed in favor of delta rpms, which are supported by rpm upstream.
It might even be that changes in rpm made it difficult or impossible to maintain that SUSE specific addon.

13

Thanks, I’ll investigate if makepatchrpm still exists at our version (and possibly later ones in case as you say its been removed for a good reason).