Re: An idea for a pkg option

On 2022-Mar-22, at 18:50, Tatsuki Makino <tatsuki_makino@hotmail.com> wrote:

> Mark Millard wrote on 2022/03/23 09:49:
>> custom: {
>>        url: "file:///usr/local/poudriere/data/packages/13_0R-amd64-default",
>>        enabled: yes,
>> }
> 
> If the package exists on local file system,
> 
> pkg delete -f llvm14
> pkg add -A -M /usr/local/poudriere/data/packages/13_0R-amd64-default/All/llvm14-14.0.0.r4.pkg
> 
> is absolutely faster :)

It is true that, for now, all my use is based on file:// .
But that need not stay that way. I've been sticking to
procedures that allow file:// use but do not require such
locality, minimizing what might have to change if I start
to do otherwise in some contexts.

Perhaps it would help if I showed an example of the
overall type of sequence:

# more ~/pkg-update-amd64-sys.sh
#! /bin/sh
pkg update \
&& pkg upgrade \
&& pkg install `cat ~/origins/amd64-pkgs.txt` \
&& pkg autoremove

In the context that I've based the examples on, the
bulk build included the very first build of devel/llvm14
but could have included builds of updates to some things
already installed. The edk2@FLAVOR builds fail, as is
currently expected/known. (Hopefully at some point they
will work again.)

As stands, listing any FLAVOR-edk2 packages in
~/origins/amd64-pkgs.txt leads to no "pkg install" for
the new devel/llvm14 (in the example context) and to
no execution of the "pkg autoremove" at all. I'd simply
like a option to make "pkg install" treat the missing
packages as acceptable, not an error. I do not
propose any change to the default behavior, suggesting
instead a new option. I could easily see others wanting
all-or-nothing instead of a possible mix from the "pkg
install".

===
Mark Millard
marklmi at yahoo.com