Re: How poudriere's PACKAGE_FETCH_WHITELIST should work?

Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp> wrote on
Date: Thu, 16 Feb 2023 08:56:08 UTC :

> On Wed, 15 Feb 2023 18:10:10 -0800
> Mark Millard <marklmi@yahoo.com> wrote:
> 
> > 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).
> 
> And poudriere (at least ports-mgmt/poudriere) sometimes fails trying to
> use "recorded as existing, but deleted for rebuild" pkgs, at least -S
> option is set. These usually are finally succeeds on next or after
> following several runs.

I  find the above unclear and so can not reasonably comment.
But I can note a limitation of what I have experience
using. This alone may also mean that my status would be
do-not-know:

I have never used poudriere bulk -S : it is documented in
part with:

QUOTE
              . . . This may result in broken
              packages if the ones they depend on are updated, are not ABI-
              compatible, and were not properly PORTREVISION bumped.
END QUOTE

I avoid dealing with noticing and fixing implicitly broken
packages, choosing the more reliable alternative that may use
more time (rebuilds that end up not installed, for example).

> Does this annoyance fixed on ports-mgmt/poudriere-devel?
> 
> > 
> > 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