Re: Why don't p5-* ports mark their dependencies?
On Jun 12, 2021, at 13:07, Bill Cole wrote: > On 2021-06-12 at 12:55:24 UTC-0400 (Sat, 12 Jun 2021 09:55:24 -0700) > Ken Cunningham is rumored to have said: > >> macports recommended perl is still 5.28 > > Which has been unsupported upstream for just over a year. The point Ken was making is that we select a specific perl (python, php, etc.) version to be the default, both in the portgroups and in default variants of individual ports. The version that is selected is typically the latest stable version at the time the selection is made. Indeed we could and should select a newer version for perl by now, but changing the selection takes effort, so someone will have to expend the effort to make that happen. Typically it has been Mojca who has done this work for previous versions, and she has begun the process of adding p5.32 modules and will presumably move on to p5.34 modules after that, and perhaps after that on to changing the default. >> $ port info perl5 >> perl5 @5.28.3 (lang) >> Sub-ports:perl5.16, perl5.18, perl5.20, perl5.22, perl5.24, >> perl5.26, perl5.28, perl5.30, perl5.32 >> Variants: perl5_26, [+]perl5_28, perl5_30 > > Odd that perl5.32 is a sub-port but perl5_32 isn't a variant. It's not odd, in that nothing in MacPorts gets done until someone does it. Nobody has yet added a perl5_32 variant, therefore none exists. The p5.32 module ports were just added en masse to MacPorts some days ago (some days after you wrote your message). There are so many of them that it will still take many days before the automated build system is finished building them. Until that's done, there's little point to offer a variant for that perl version for the perl5 port. > Someone could make a full-time+ job of maintaining just the Perl packages in > MacPorts. Or indeed any other sufficiently large subset of ports. Many of our maintainers do spend a great deal of time maintaining a great many ports, for which I thank them! :)
Re: Why don't p5-* ports mark their dependencies?
On Jun 12, 2021, at 12:39, Kastus Shchuka wrote: >> sudo port upgrade --enforce-variants git -perl5_28 +perl5_30 > > Thank you, that worked and allowed me to uninstall all p5.28 modules. > > What puzzles me still, why port info shows that git depends on perl 5.28 > modules: > > $ port info git > git @2.32.0 (devel) > Variants: [+]credential_osxkeychain, [+]diff_highlight, [+]doc, > gitweb, [+]pcre, perl5_26, [+]perl5_28, > perl5_30, python, svn, universal > > Description: Git is a fast, scalable, distributed open source > version control system focusing on speed and > efficiency. > Homepage: https://git-scm.com/ > > Extract Dependencies: xz > Library Dependencies: perl5.28, curl, zlib, openssl, expat, libiconv, pcre2 > Runtime Dependencies: p5.28-authen-sasl, p5.28-error, p5.28-net-smtp-ssl, > p5.28-term-readkey, p5.28-cgi, rsync > Platforms:darwin > License: GPL-2 and LGPL-2.1+ > Maintainers: Email: ciserl...@macports.org, GitHub: ci42 > Policy: openmaintainer > $ port installed and git > The following ports are currently installed: > git @2.31.1_2+credential_osxkeychain+diff_highlight+doc+pcre+perl5_30 > git @2.32.0_0+credential_osxkeychain+diff_highlight+doc+pcre+perl5_30 > (active) Because git, with its default perl5_28 variant, does depend on p5.28 modules. "port info" does not take into account the variants you have selected when installing the port. Rather, it shows you the info of the port with its default variants. If you want to see the info with a different set of variants you can specify them, e.g. "port info git +perl5_30"
Re: Why don't p5-* ports mark their dependencies?
On Sat, Jun 12, 2021 at 06:02:25PM -0700, Ken Cunningham wrote: > I think Bill perhaps then you really want to open a thread with the title: > > “I would like to suggest we move MacPorts default perl to 5.30 now”. > > And then let the conversation happen, and if the outcome is “Yes” then that > will happen. > > Or 5.32. Whatever you care to suggest. > > But trying to fight against the current default recommended perl, whatever it > is, is kind of a waste of precious time and effort. > > Ken 5.34 has just been released, so 5.32 might be better. but they're all fine choices. cheers, raf
Re: Why don't p5-* ports mark their dependencies?
I think Bill perhaps then you really want to open a thread with the title: “I would like to suggest we move MacPorts default perl to 5.30 now”. And then let the conversation happen, and if the outcome is “Yes” then that will happen. Or 5.32. Whatever you care to suggest. But trying to fight against the current default recommended perl, whatever it is, is kind of a waste of precious time and effort. Ken
Re: Why don't p5-* ports mark their dependencies?
On 2021-06-12 at 12:55:24 UTC-0400 (Sat, 12 Jun 2021 09:55:24 -0700) Ken Cunningham is rumored to have said: macports recommended perl is still 5.28 Which has been unsupported upstream for just over a year. 5.30 just fell out of support a few weeks ago. They are doing a major release every year and only supporting the current and prior stable releases. "Pace" is all the rage these days, having supplanted "stability." I still have stable production on 5.28.3 because of some known issues in 5.30 and later with code hygiene, but I need to work on those issues so a 5.30 test system (and soon 5.32) is necessary for me. $ port info perl5 perl5 @5.28.3 (lang) Sub-ports:perl5.16, perl5.18, perl5.20, perl5.22, perl5.24, perl5.26, perl5.28, perl5.30, perl5.32 Variants: perl5_26, [+]perl5_28, perl5_30 Odd that perl5.32 is a sub-port but perl5_32 isn't a variant. so that is supposed to be the default perl for everything, until such time as that is changed to perl 5.30. So if you want perl 5.30 for everything, you will be fighting upstream at every turn. I see it more as opening a second front downstream of MacPorts in alliance with the Perl upstream. :) Someone could make a full-time+ job of maintaining just the Perl packages in MacPorts. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Why don't p5-* ports mark their dependencies?
> On Jun 12, 2021, at 9:54 AM, Rainer Müller wrote: > > On 12/06/2021 18.32, Bill Cole wrote: >> On 2021-06-12 at 12:11:47 UTC-0400 (Sat, 12 Jun 2021 09:11:47 -0700) >> Kastus Shchuka >> is rumored to have said: >> >>> I wish it could be so easy to remove perl5.28. Apparently, I have to >>> keep it because of git: >> >> port uninstall git >> port install git -perl5_28 +perl5_30 > > sudo port upgrade --enforce-variants git -perl5_28 +perl5_30 > Thank you, that worked and allowed me to uninstall all p5.28 modules. What puzzles me still, why port info shows that git depends on perl 5.28 modules: $ port info git git @2.32.0 (devel) Variants: [+]credential_osxkeychain, [+]diff_highlight, [+]doc, gitweb, [+]pcre, perl5_26, [+]perl5_28, perl5_30, python, svn, universal Description: Git is a fast, scalable, distributed open source version control system focusing on speed and efficiency. Homepage: https://git-scm.com/ Extract Dependencies: xz Library Dependencies: perl5.28, curl, zlib, openssl, expat, libiconv, pcre2 Runtime Dependencies: p5.28-authen-sasl, p5.28-error, p5.28-net-smtp-ssl, p5.28-term-readkey, p5.28-cgi, rsync Platforms:darwin License: GPL-2 and LGPL-2.1+ Maintainers: Email: ciserl...@macports.org, GitHub: ci42 Policy: openmaintainer $ port installed and git The following ports are currently installed: git @2.31.1_2+credential_osxkeychain+diff_highlight+doc+pcre+perl5_30 git @2.32.0_0+credential_osxkeychain+diff_highlight+doc+pcre+perl5_30 (active) git works, as far as I can test. Thanks, Kastus
Re: Why don't p5-* ports mark their dependencies?
macports recommended perl is still 5.28 $ port info perl5 perl5 @5.28.3 (lang) Sub-ports:perl5.16, perl5.18, perl5.20, perl5.22, perl5.24, perl5.26, perl5.28, perl5.30, perl5.32 Variants: perl5_26, [+]perl5_28, perl5_30 so that is supposed to be the default perl for everything, until such time as that is changed to perl 5.30. So if you want perl 5.30 for everything, you will be fighting upstream at every turn. Ken
Re: Why don't p5-* ports mark their dependencies?
On 12/06/2021 18.32, Bill Cole wrote: > On 2021-06-12 at 12:11:47 UTC-0400 (Sat, 12 Jun 2021 09:11:47 -0700) > Kastus Shchuka > is rumored to have said: > >> I wish it could be so easy to remove perl5.28. Apparently, I have to >> keep it because of git: > > port uninstall git > port install git -perl5_28 +perl5_30 sudo port upgrade --enforce-variants git -perl5_28 +perl5_30 https://guide.macports.org/#using.port.upgrade Rainer
Re: Why don't p5-* ports mark their dependencies?
On 2021-06-12 at 12:11:47 UTC-0400 (Sat, 12 Jun 2021 09:11:47 -0700) Kastus Shchuka is rumored to have said: I wish it could be so easy to remove perl5.28. Apparently, I have to keep it because of git: port uninstall git port install git -perl5_28 +perl5_30 -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Why don't p5-* ports mark their dependencies?
I wish it could be so easy to remove perl5.28. Apparently, I have to keep it
because of git:
$ port info git
git @2.31.1_2 (devel)
Variants: [+]credential_osxkeychain, [+]diff_highlight, [+]doc,
gitweb, [+]pcre, perl5_26, [+]perl5_28,
perl5_30, python, svn, universal
Description: Git is a fast, scalable, distributed open source version
control system focusing on speed and
efficiency.
Homepage: https://git-scm.com/
Extract Dependencies: xz
Library Dependencies: perl5.28, curl, zlib, openssl, expat, libiconv, pcre2
Runtime Dependencies: p5.28-authen-sasl, p5.28-error, p5.28-net-smtp-ssl,
p5.28-term-readkey, p5.28-cgi, rsync
Platforms:darwin
License: GPL-2 and LGPL-2.1+
Maintainers: Email: ciserl...@macports.org, GitHub: ci42
Policy: openmaintainer
Are Library and Runtime dependencies of git on perl5.28 intentional or an
oversight?
Thanks,
Kastus
> On Jun 12, 2021, at 8:34 AM, Bill Cole
> wrote:
>
> On 2021-06-09 at 15:51:09 UTC-0400 (Wed, 9 Jun 2021 15:51:09 -0400)
> Daniel J. Luke
> is rumored to have said:
>
>> On Jun 6, 2021, at 1:41 PM, Bill Cole
>> wrote:
>>> I *think* I've even worked out the right way to use that construct to make
>>> Perl upgrades simpler, so I use the p5-* ports:
>>
>> I gave up on trying to use this in any useful way a while ago - if you've
>> got some way that it works, please share.
>
> According to my shell history, this is what I did to clear out all the old
> perl5.2[68] and
>
> port deactivate perl5
> port install perl5 +perl5_30
> port deactivate perl5.26
> port deactivate perl5.28
> port installed|grep '^ p5\.2.*-' |awk '{print $1}'|while read x; do y=`echo
> $x|sed 's/\.2.-/-/'`; port -v -f deactivate $x ; port -v install $y; done
>
> Adjust to suit whatever versions you're trying to remove/replace.
>
> --
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire
Re: Why don't p5-* ports mark their dependencies?
On 2021-06-09 at 15:51:09 UTC-0400 (Wed, 9 Jun 2021 15:51:09 -0400)
Daniel J. Luke
is rumored to have said:
On Jun 6, 2021, at 1:41 PM, Bill Cole
wrote:
I *think* I've even worked out the right way to use that construct to
make Perl upgrades simpler, so I use the p5-* ports:
I gave up on trying to use this in any useful way a while ago - if
you've got some way that it works, please share.
According to my shell history, this is what I did to clear out all the
old perl5.2[68] and
port deactivate perl5
port install perl5 +perl5_30
port deactivate perl5.26
port deactivate perl5.28
port installed|grep '^ p5\.2.*-' |awk '{print $1}'|while read x; do
y=`echo $x|sed 's/\.2.-/-/'`; port -v -f deactivate $x ; port -v install
$y; done
Adjust to suit whatever versions you're trying to remove/replace.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: Why don't p5-* ports mark their dependencies?
On Jun 6, 2021, at 12:41, Bill Cole wrote: > Not sure where the bug is here, but it's evident in 'port reclaim'. > > The p5-* ports are basically placeholders for the p5.##- ports. I *think* > I've even worked out the right way to use that construct to make Perl > upgrades simpler, so I use the p5-* ports: > > $ sudo port install p5-net-cidr p5-term-readline p5-test-fatal > ---> Computing dependencies for p5-net-cidr > The following dependencies will be installed: p5.30-net-cidr > Continue? [Y/n]: y > ---> Fetching archive for p5.30-net-cidr > ---> Attempting to fetch > p5.30-net-cidr-0.200.0_0.darwin_18.noarch.tbz2 from > https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-net-cidr > ---> Attempting to fetch > p5.30-net-cidr-0.200.0_0.darwin_18.noarch.tbz2.rmd160 from > https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-net-cidr > ---> Installing p5.30-net-cidr @0.200.0_0 > ---> Activating p5.30-net-cidr @0.200.0_0 > ---> Cleaning p5.30-net-cidr > ---> Cleaning p5-net-cidr > ---> Computing dependencies for p5-term-readline > The following dependencies will be installed: p5.30-term-readline > Continue? [Y/n]: y > ---> Fetching archive for p5.30-term-readline > ---> Attempting to fetch > p5.30-term-readline-1.140.0_0.darwin_18.noarch.tbz2 from > https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-term-readline > ---> Attempting to fetch > p5.30-term-readline-1.140.0_0.darwin_18.noarch.tbz2.rmd160 from > https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-term-readline > ---> Installing p5.30-term-readline @1.140.0_0 > ---> Activating p5.30-term-readline @1.140.0_0 > ---> Cleaning p5.30-term-readline > ---> Cleaning p5-term-readline > ---> Computing dependencies for p5-test-fatal > The following dependencies will be installed: p5.30-test-fatal > Continue? [Y/n]: y > ---> Fetching archive for p5.30-test-fatal > ---> Attempting to fetch > p5.30-test-fatal-0.16.0_0.darwin_18.noarch.tbz2 from > https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-test-fatal > ---> Attempting to fetch > p5.30-test-fatal-0.16.0_0.darwin_18.noarch.tbz2.rmd160 from > https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-test-fatal > ---> Installing p5.30-test-fatal @0.16.0_0 > ---> Activating p5.30-test-fatal @0.16.0_0 > ---> Cleaning p5.30-test-fatal > ---> Cleaning p5-test-fatal > ---> Scanning binaries for linking errors > ---> No broken files found. > ---> No broken ports found. > > Perfectly normal, right? > > However, immediately after doing that, I did a reclaim and got a surprise: > > $ sudo port -v reclaim > ---> Checking for unnecessary unrequested ports > Unrequested ports without requested dependents found: >p5.30-test-fatal @0.16.0_0 >p5.30-net-cidr @0.200.0_0 >p5.30-term-readline @1.140.0_0 > Would you like to uninstall them? [Y/n]: n > > And the dependency map is not reversible: > > $ port deps p5-net-cidr > Full Name: p5-net-cidr @0.200.0_0 > Library Dependencies: p5.30-net-cidr > $ port rdependents p5.30-net-cidr > p5.30-net-cidr has no dependents. Yes, the p5 ports are a bit weird in that regard. The p5-* ports can be installed -- they install essentially nothing (a placeholder text file) themselves but depend on e.g. the corresponding p5.30-* port which then gets installed. But also, the p5-* ports are marked as being replaced_by the corresponding p5.30-* port. This is unusual. Normally, when a port uses the replaced_by feature, the port also prevents itself from being able to be installed. The php-* and python-* ports do not use the replaced_by feature in this way; maybe the p5-* ports shouldn't do that either. Maybe that would cure the issue you observed.
Re: Why don't p5-* ports mark their dependencies?
On Jun 6, 2021, at 1:41 PM, Bill Cole wrote: > I *think* I've even worked out the right way to use that construct to make > Perl upgrades simpler, so I use the p5-* ports: I gave up on trying to use this in any useful way a while ago - if you've got some way that it works, please share. (FWIW, things would 'just work' if we'd ship the current version of perl5 and only have p5-foo ports). For anything outside of MacPorts I recommend using perlbrew and just letting the macports perl install be only for things installed via macports. -- Daniel J. Luke
