Re: How poudriere's PACKAGE_FETCH_WHITELIST should work?

On Feb 15, 2023, at 17:22, Tatsuki Makino <tatsuki_makino@hotmail.com> wrote:

> I was introduced to this feature in a reply to an email titled "[through-able] poudriere: I don't want to rebuild rust with PORTREVISION bump of curl" that I wrote on or about 2023-01-20.
> 
> This still means that the dependencies held in the package must match up to the version number to be used, right?
> As I wrote in that e-mail, the dependent packages can be checked with the following command, which poudriere also seems to use.
> pkg query -F somewhere/llvm10-10.0.1_10.pkg '%do %dn-%dv'
> 
> In the current porttree, python39 is 3.9.16_1. If this package has already been created locally, it would seem that the llvm* package that depends on python39-3.9.16 or earlier would not be used when fetched, is that correct?
> 
> # note that I avoided recreating llvm13 and llvm15 that way :)
> 

Turns out my notes did not apply: the person I replied to was
using quarterly and so things were apparently not changing.

But I'd not checked the transitive closures for the various
ports involved for the 2023Q1 context. Using rust and its
curl dependency as an example:

curl in turn depends on at least devel/pkgconf , lang/perl5.32 ,
security/ca_root_nss , www/libnghttp2 , security/libssh2 ,
and dns/libpsl . So there is a fair list of things that can
cause curl to rebuild, which in turn leads to rust potentially
rebuilding, even if the rebuild result for rust ends up not
being installed for lack of a version bump: existing install
is still expected to be compatible given the lack of a version
bump.

The way rebuilds happen is that an update to the likes of,
say, security/libssh2 deletes the old package. Then curl's
package is deleted because of the lack of a package for
security/libssh2 . (This is before security/libssh2 or
anything is rebuilt.) Then rust for similar reasons. Deleting
the packages does not delete the installs (important later).
Then the deleted packages are rebuilt so that they are
available to future pkg commands, even if it turns out that
some of the installed ones would not be updated by the likes
of a "pkg upgrade" in the same time frame (version numbering).

Again, I've not gone looking for changes in the transitive
closure of the dependencies. I'm just noting some of the
general structure. I've not checked if this explains all the
specifics that happened.

Going in the other direction, there may be more that is
involved than I know about. But I've observed the delete
sequences and later rebuild sequences that do not lead
to updated installs of various things rebuilt. (A lot over
the years.)

===
Mark Millard
marklmi at yahoo.com