randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

Jason Liu jasonliu at umich.edu
Tue Jun 23 03:26:53 UTC 2020


>
> We should just have one perl5 port that tracks the current release. We'd
> just need to either revbump everything that needs a rebuild when a new
> minor perl version comes out (all the p5- ports to start) OR some
> enhancement to base to make it so the revbump is unnecessary.
>


> It might be an idea for the admins to "set" the perl version all ports
> will use (barring some actual real need for another), and then ---
> all-at-once -- change it to some new version to avoid this.
>

I think python might be another compiler/interpreter which could benefit
from such a system.

Either going with Dan's method of having a one python3 port that tracks the
current release, and a corresponding set of py3-* ports that track the
python3 port. Or, going with Ken's method and "setting" the default python
version that all ports will use.

Either of those methods could help to reduce or eliminate what's happening
right now in lots of portfiles, where the portfile author basically has to
arbitrarily pick a version of python to use as the portfile's default.

-- 
Jason Liu


On Mon, Jun 22, 2020 at 3:34 PM Daniel J. Luke <dluke at geeklair.net> wrote:

> On Jun 22, 2020, at 10:59 AM, Ken Cunningham <
> ken.cunningham.webuse at gmail.com> wrote:
> > Perhaps unavoidable in some cases, but if you look around the web, this
> is in fact the #1 complaint about MacPorts: bloat.
>
> It's somewhat ironic given the current trend of everything being
> containerized (and bringing in all of their duplicate dependencies inside
> their containers)>
>
> > It might be an idea for the admins to "set" the perl version all ports
> will use (barring some actual real need for another), and then ---
> all-at-once -- change it to some new version to avoid this.
> >
> > And ideally we could look at changing it once every few years.
>
> We should just have one perl5 port that tracks the current release. We'd
> just need to either revbump everything that needs a rebuild when a new
> minor perl version comes out (all the p5- ports to start) OR some
> enhancement to base to make it so the revbump is unnecessary.
>
> We could keep the 'old' perl5s around - but I would suggest that it's not
> worthwhile. People who really need multiple versions of perl are better
> served by using perlbrew than any of the packagers.
>
> --
> Daniel J. Luke
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200622/39040283/attachment-0001.htm>


More information about the macports-dev mailing list