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>