A small release: two commits, two files. port.pm starts recording PKGVERSION as make reports it, instead of leaving every consumer to compose a package version out of version, revision and portepoch — which was wrong for about a hundred ports. config.pm.sample gains the flag which lets the nightly INDEX comparison queue its own refresh job. Both halves belong to the same piece of work as ingress/scripts, and the first of them cannot be deployed without it.
- Release:
ingress/modules2.3.0. Ofr6226–r6270, two revisions touch this module:r6260andr6270. Previous release 2.2.2 was cut atr6225. - Files:
port.pm,config.pm.sample - Requires, in this order: the
ports.pkgversioncolumn fromdatabase-schemar6262, then this release and the matchingingress/scriptsrelease together. Deploying either of those two alone corrupts every port it touches. See “Installing” below. - Config: one new value in
config.pm,$FreshPorts::Config::RefreshFromIndexFlag. No new dependencies. - Tested on: dev-ingress01, through the nightly comparison and through
set-pkgversion.placross the tree. - Rollback to: 2.2.2, with
ingress/scriptsrolled back in the same step. The new column can stay.
Record PKGVERSION, which is not always what we compose
r6260. File: port.pm
FreshPorts stored version, revision and portepoch, and everything which needed a package version composed them: version, then _revision, then ,portepoch. That is not always what the port builds as. audio/oss has PORTVERSION 4.2.b2019 and PORTREVISION 5, which compose to 4.2.b2019_5, but its PKGVERSION is 4.2.b2019.1501000_5. The kmod framework splices ${OSVERSION} in between the version and the revision, where none of the variables we fetched could show it. Host and jail agree on the value, so it is not environmental. Around a hundred ports are affected, and no amount of composing would ever have produced their real version, because the component was never fetched.
make-port.shnow asks forPKGVERSIONandport.pmrecords it inports.pkgversion. Five touch points, the same five every othermake -Vvariable has:_initialize,_GetValuesFromRow, the_saveUPDATE, thesplit, and the debug print.- It is asked for last, which fixes a bug that was there before this work.
splitwith no limit discards trailing empty fields, so$use_rc_subr— the last field until now — was left undefined for any port which does not setUSE_RC_SUBR, which is most of them.PKGVERSIONis never empty, so it now shields the field which could be. - Nothing the site displays changes as a result of this commit.
version,revisionandportepochare untouched;pkgversionexists to be compared against the INDEX. - The column is NULL until a port has been refreshed, so nothing can rely on it on the day it ships. Once every port has been through a refresh,
compare-index.shcan compare it directly, and the two OSVERSION regexes, the composing with itsNOT IN ('', '0')cases, and most of the(empty)handling all go away.
Schedule a refresh when the comparison finds work
r6270. File: config.pm.sample
The nightly comparison had been finding ports whose version was out of date and then doing nothing about them. It now raises a flag which job-waiting.pl picks up.
- One new value:
$FreshPorts::Config::RefreshFromIndexFlag,${BaseDir}/signals/refresh_from_index. It is the same path asREFRESHFROMINDEXFLAGinconfig.sh, since the shell raises the flag and perl reads it. Set them to the same thing or the job never runs. - The rest of this change is in
ingress/scripts:job-waiting.plmaps the flag torefresh-from-index.sh, which runsrefresh-listed-ports.plagainst the list the comparison wrote. - The flag goes up only when the list has something in it. Most nights it does not, and raising it anyway would start a job with nothing to do.
Installing
ports.pkgversionfirst.database-schemar6262.port.pmnames the column in itsUPDATE, so with this release installed against a database without it, every port refresh fails.- This release and
ingress/scriptsin one step.make-port.shruns onemake -Vwith 49 variables andport.pmassigns them by position, 49 names against 49 values. A mismatched pair does not fail — it puts every field after the mismatch into the wrong column, and keeps doing so until someone notices. Both packages carry one half of that contract. - Add
$FreshPorts::Config::RefreshFromIndexFlagtoconfig.pm, matchingREFRESHFROMINDEXFLAGinconfig.sh. - Run the
set-pkgversion.plbackfill from thescriptspackage. Until it has run,pkgversionis NULL for every port which has not happened to be refreshed, so anything reading it sees a mostly empty column.
If this host is coming from a release earlier than 2.2.2, that release’s ports.build_run_depends column and its EXTRACT_DEPENDS/PATCH_DEPENDS data migration are prerequisites too, and the same positional argument applies to them.
Smoke tests after install
| Check | Expect |
|---|---|
| Refresh any port with debug on | A pkgversion = '…' line in the dump, non-empty |
Refresh a port which does not set USE_RC_SUBR | use_rc_subr = '' and no uninitialised-value warning |
| Refresh a port which does set it | Its USE_RC_SUBR value, unchanged from before this release — confirms the 49 fields still line up |
Refresh audio/oss | pkgversion = 4.2.b2019.1501000_5, while version stays 4.2.b2019 and revision stays 5 |
| Any port page | Unchanged. This release alters nothing the site reads. |
touch $RefreshFromIndexFlag | job-waiting.pl runs refresh-from-index.sh and the flag is gone afterwards |
The third row is the one worth doing deliberately. A positional mismatch is silent, and the only cheap way to see it is to refresh a port whose later fields have known values and read them back.
Rollback
Back to 2.2.2, and ingress/scripts back in the same step — the two move together in either direction, for the same reason they install together. ports.pkgversion can stay: nothing reads it with the old port.pm in place, and leaving it means the backfill is not thrown away if this is reinstalled. Values written while this release was live stay correct; they simply stop being updated.
