[MacPorts] #67869: p5* ports - what a mess (IMHO, YMMV &c! (was: p5* ports - what a mess!)
MacPorts
noreply at macports.org
Sun Jul 30 21:04:54 UTC 2023
#67869: p5* ports - what a mess (IMHO, YMMV &c!
---------------------+--------------------
Reporter: RJVB | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: | Keywords:
Port: perl5 |
---------------------+--------------------
Comment (by RJVB):
Replying to [comment:2 ryandesign]:
The title was meant to be provocative but I could have made it more clear
that it's my opinion.
> It has been this way since perl5 and the p5- ports were split into
submodules in 2011 (#30638).
MacPorts has evolved considerably since then, so there must be a more
convenient and cleaner way to do this nowadays.
> Granted that commit message does not say why but there was probably
mailing list discussion approving the plan
But who goes scavenging through mailing list archives to find such
discussions?!
> > (and frankly, that variable should be set in a PG and only overridden
in individual Portfiles when unavoidable).
>
> No. Portfiles are only indexed when they are modified.
As a sidebar, that too is something that could end probably should be
modified because it's counter-intuitive to anyone used to programming.
But the revision mechanism exists for this purpose, which probably a whole
lot simpler to use in a script than a more complex edit.
Also, it is not impossible that the majority of ports do not need to be
revbumped. As you say, perl5 is mature and rarely breaks ABI, very few
perl ports install binaries (2 our of 146 for me; they do not link to
libperl.dylib) and the rest simply don't need to be revbumped unless there
are known incompatibilities.
> > Also, I see the perl5 PG now ''misdefines'' `perl5.major` as
`major.minor`, which is probably part of the reason of the mess.
>
> As far as I know, the perl module ports work as intended, so I would
hesitate to say that anything is misdefined. How is `perl5.major` defined,
and how do you think it should be defined instead?
`perl5.major` is currently defined as `major.minor` (so 5.28 in the
current snapshot I have). Now I haven't checked if there's a Perl 6 but a
priori the major version here is `5`.
> Correct, it is not.
So that's a good thing for the kind of change I was proposing.
> The pros and cons of switching to that method could be discussed. One
con is that it be different from how we handle most other languages in
MacPorts (python, php, ruby...).
I cannot speak for the other two, but Python is different here in that
binaries are much more common and they do link to a library from the main
port. Plus the language is designed to have a version-specific "site-
packages" or "dist" directory where packages are installed. Perl doesn't
seem to have that (which is already a good indication that it isn't
necessary).
> But it took considerable effort (even the invention of the subport
feature of MacPorts!) to implement it in the first place and it would take
considerable effort to de-implement it again, even if we agreed it was a
good idea to do so.
As I said, there's no need to de-implement it. Either the p5-* ports start
depending on `port:perl5` which provides some default version or there
could be a `port:perl5.x` (x not being a number) with the corresponding
p5.x-* ports. The former approach should be transparent for all ports that
are now version-agnostic dependent on perl5.
> The user is expected to run `sudo port reclaim` (or just `sudo port
uninstall obsolete`) periodically.
I assume that gives very little control over what gets uninstalled, just
like the `-u` option will uninstall all older (if not all other) versions
of a port. Fine for Joe & Jane User but for more advanced users who always
want to keep at least 1 older version around it's just not an option.
> I don't think macports.conf at present contains any settings related to
any specific port or portgroup and it's probably good to keep it that way.
You can set default variants in there (or an equivalent file), which can
very well be specific to a single port or portgroup. Idem for the
environment variables to preserve (I don't know if the feature is used
that way or if it would be condoned).
NB: the perl5 PG defines variants for perl5 versions. I don't see a clear
documentation in the PG what this is supposed to do but using a version-
specific variant would do the trick just as well (though more awkwardly)
as using a version-defining variable.
--
Ticket URL: <https://trac.macports.org/ticket/67869#comment:3>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list