Date: Mon, 23 Oct 2023 08:03:43 +0900 From: Tatsuki Makino <tatsuki_makino@hotmail.com> To: Kevin Oberman <rkoberman@gmail.com>, "freebsd-ports@FreeBSD.org" <freebsd-ports@freebsd.org> Subject: Re: lang/perl5.36: update procedure written in UPDATING is not enough Message-ID: <TYZPR01MB50375EC41B2B9E7AEDA77E8CFAD9A@TYZPR01MB5037.apcprd01.prod.exchangelabs.com> In-Reply-To: <CAN6yY1tNv5NfORn=25WzxpzesmukubE4D1n_jXjDMaBP=yHO0A@mail.gmail.com> References: <202310211305.39LD5Qt8086896@nuc.oldach.net> <SI2PR01MB5036F4F881FCB6005E220CCCFADAA@SI2PR01MB5036.apcprd01.prod.exchangelabs.com> <CAN6yY1tNv5NfORn=25WzxpzesmukubE4D1n_jXjDMaBP=yHO0A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Oberman wrote on 2023/10/22 13:12: > I think portmaster has a bug. As per the man page, the behavior of '-f' > matches the behavior of '-R -f". Actually, I'm unclear on what the purpose > '-f' is. If you run portmaster with no options on a port that is up to > date, it still reinstalls it and has for a very long time, maybe always. It is not so much a bug as a behavior that requires strange thinking :) At least -f is valid for the -a option. I rarely use it :) portmaster -a -f # This is definitely something that will fail :) portmaster -a -f -R # After repairing something that failed, continue with the rest. No need to build rust or gcc twice :) I have never used -f in combination with individual ports. Or even using -f for it, but never thought much about it :) The following is a speculative explanation of the behavior, which differs from the actual implementation... If used without options, it is assumed to be already moved to and used in a port directory somewhere in porttree. cd /usr/ports/ports-mgmt/pkg && portmaster Otherwise, it tries to make with Makefile in the current directory, or make in HOME directory. They are bugs :) Now assume two imaginary flags. One flag is to forcefully update, and the other is to use a mechanism to allow a restart in case of failure. When using -a, all installed ports are queued. But they are not all forcefully updated. Only those with increased version numbers will be updated. If -f is used there, all of them will be flagged to be forced to update and to be restartable in case of failure. -R can be used. If individual ports are given as arguments, they will be queued and flagged which will force them to be updated. If -f is used there, it is already determined to force update, so it only activates the feature that allows restart on failure. So it would seem that there is such a difference :) The above two flags change depending on the -f option and the way the port to be updated is given. When restarting by -R, it seems to me that the ports to be queued must be exactly the same to go. For example, if executed as follows portmaster -f `pkg shlib -qR libperl.so.5.34` portmaster -f -R `pkg shlib -qR libperl.so.5.34` The number of arguments when using -R is reduced by the number of successfully updated ports. ... I estimated this as such :) If not, first I need to see what's in portmaster more. However, this is a tool that has existed since the last generation, so there may still be many behaviors that do not fit with pkgng. Regards.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?TYZPR01MB50375EC41B2B9E7AEDA77E8CFAD9A>