What is the difference between p0 and p3?

[ed.n1n2]

Hi all,

A little new to OpenBSD. One of the first things I did was to look at the Errata, and from their I ended up choosing M:Tier for my updates.

Afterwards, I've noticed that when updating or installing packages, I create ambiguous choices most of the time as so:

quirks-2.9 signed on 2014-08-02T11:06:13Z
Ambiguous: choose package for nginx
 a       0: None
         1: nginx-1.4.7p0
         2: nginx-1.4.7p0-lua
         3: nginx-1.4.7p0-naxsi
         4: nginx-1.4.7p0-passenger
         5: nginx-1.5.7p3
         6: nginx-1.5.7p3-lua
         7: nginx-1.5.7p3-naxsi
         8: nginx-1.5.7p3-passenger
Your choice:

What is the functional difference between p0 and p3 in this case?

(I know the differences between lu, naxsi, and passenger)

[rocket357]

If I'm not mistaken, that is an extension to the version, and it stands for the patch revision level (i.e. nginx 1.5.7, with all of the patchsets up to an including the third patchset installed).

Anyone care to clarify if I got that garbled?

[TronDD]

Well the more import part there is 1.4 vs 1.5.

But the p value represents when the port changes but the version of the utility hasn't.

Tim.

[jggimi]

Hello, and welcome!

Any revision to the port -- Makefile, patches, packing list, even a change to the text of a local README file -- that did not come from a change to the software from the upstream project results in a "p" number, which start with zero.

See the REVISION environment variable's many mentions in bsd.port.mk(5) and additional comments in packages-specs(7).

[Oko]

Originally Posted by jggimi

Hello, and welcome!

Any revision to the port -- Makefile, patches, packing list, even a change to the text of a local README file -- that did not come from a change to the software from the upstream project results in a "p" number, which start with zero.

See the REVISION environment variable's many mentions in bsd.port.mk(5) and additional comments in packages-specs(7).

This is a damn good post!

[ibara]

To be ultra-pedantic:
REVISION is bumped whenever there is a change in the final package as distributed by us. A change to a port might not result in a change to the package. In that case, REVISION would not be bumped. Changing MASTER_SITES immediately comes to mind as such a change.

What REVISION actually does is trigger the build machines to rebuild the package at next go-around.

[jggimi]

Thanks for the additional clarification!

To the best of my recollection, revision bumps to my few ports have resulted from committers revising Makefiles rather than anything I happened to submit.

I also use REVISION to track local port customizations -- e.g.: "REVISION=0jggimi".

(I'm not recommending local customizations, I just happen to use one to add a needed subtitling library to graphics/ffmpeg. Yes, I've discussed the library with the MAINTAINER. Brad may consider it in a future restructuring.)

[ed.n1n2]

Thanks guys!!

Now it makes sense