Date: Thu, 16 Feb 2023 13:43:36 -0800 From: Mark Millard <marklmi@yahoo.com> To: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>, FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: How poudriere's PACKAGE_FETCH_WHITELIST should work? Message-ID: <BF4B8F6E-2B21-42F2-876D-F298C927F3B8@yahoo.com> References: <BF4B8F6E-2B21-42F2-876D-F298C927F3B8.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>=20
> > On Feb 15, 2023, at 17:22, Tatsuki Makino =
<tatsuki_makino@hotmail.com> wrote:
> >=20
> > > 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.
> > >=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'
> > >=20
> > > 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?
> > >=20
> > > # note that I avoided recreating llvm13 and llvm15 that way :)
> > >=20
> >=20
> > Turns out my notes did not apply: the person I replied to was
> > using quarterly and so things were apparently not changing.
> >=20
> > 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:
> >=20
> > 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.
> >=20
> > 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).
>=20
> 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?
>=20
> >=20
> > 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.
> >=20
> > 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.)
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BF4B8F6E-2B21-42F2-876D-F298C927F3B8>