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

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Ken Cunningham
A simple used-to-be-quick  build of "curl" now requires two different perls installed.

Perhaps unavoidable in some cases, but if you look around the web, this is in fact the #1 complaint about MacPorts: bloat.

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.

Ken
Reply | Threaded
Open this post in threaded view
|

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

Marius Schamschula-3
Agreed.

I’ve chosen to have my main build machine run perl5.30, but that causes ports like help2man to try to reinstall perl5.28.

On my FreeBSD machines you set the Perl branch in /etc/make.conf, and all the Makefiles respect that setting.

Marius
--
Marius Schamschula




On Jun 22, 2020, at 9:59 AM, Ken Cunningham <[hidden email]> wrote:

A simple used-to-be-quick  build of "curl" now requires two different perls installed.

Perhaps unavoidable in some cases, but if you look around the web, this is in fact the #1 complaint about MacPorts: bloat.

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.

Ken

Reply | Threaded
Open this post in threaded view
|

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

Daniel J. Luke
In reply to this post by Ken Cunningham
On Jun 22, 2020, at 10:59 AM, Ken Cunningham <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Dr M J Carter-2
On Mon, Jun 22, 2020 at 03:34:39PM -0400, Daniel J. Luke wrote:
> On Jun 22, 2020, at 10:59 AM, Ken Cunningham <[hidden email]> 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)

Rats: you beat me to it.  I'll restrict myself to reminiscing about
dylibs having allegedly been invented (by Sun?) out of embarrassment,
on finding hello.c was bloated, to 3MBytes iirc, by printf() dragging
in half the known universe at link time.

We now return you to your normal programming.

--
Dr Martin J Carter
Computer System Administrator (Mon--Wed only)
Astrophysics but WFH, University of Oxford
Reply | Threaded
Open this post in threaded view
|

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

Michael_google gmail_Gersten

On 2020-06-22, at 1:12 PM, Dr M J Carter <[hidden email]> wrote:

> Rats: you beat me to it.  I'll restrict myself to reminiscing about
> dylibs having allegedly been invented (by Sun?) out of embarrassment,
> on finding hello.c was bloated, to 3MBytes iirc, by printf() dragging
> in half the known universe at link time.

Oh, it's not all that bad. Just the standard io library, the file buffering library, the larger startup and exit code, math library (because some of the formatting options required something, probably rounding, I have long since forgotten), error text translation (gotta be able to report the error numbers as human readable text, after all), some string library routines -- oh, right, that's ALL of the string library, and ... did I leave anything out?

---
Entertaining minecraft videos
http://YouTube.com/keybounce

Reply | Threaded
Open this post in threaded view
|

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

ryandesign2
Administrator
In reply to this post by Ken Cunningham


On Jun 22, 2020, at 09:59, Ken Cunningham wrote:

> A simple used-to-be-quick  build of "curl" now requires two different perls installed.
>
> Perhaps unavoidable in some cases, but if you look around the web, this is in fact the #1 complaint about MacPorts: bloat.
>
> 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.

I thought we already had a tendency to do that. perl5.28 is the standard version to use in MacPorts today. Some ports were recently switched to perl5.30. There was a discussion complaining about that. They were switched back to perl5.28. If any others have not yet been switched back they probably should be.

Reply | Threaded
Open this post in threaded view
|

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

ryandesign2
Administrator
In reply to this post by Daniel J. Luke
I've just realized this discussion has been to the old list address from macosforge. Please always use the new list addresses at lists.macports.org.


On Jun 22, 2020, at 14:34, Daniel J. Luke wrote:

> We should just have one perl5 port that tracks the current release.

You say this every year (or at least often).

Are you volunteering to be the one to ensure that every port that uses perl is compatible with the new perl release when it comes out? Without someone to do that, blindly upgrading everything from say perl 5.28 to 5.30 will likely break ports.

Do you remember perl 5.26? It broke a lot of ports, requiring a lot of fixes like this to be added: https://github.com/macports/macports-ports/commit/454eb2b0608266ab7bdf51a82d690be0f97610fe

The strategy currently being employed by those volunteers who are maintaining the perl ports is to keep everything defaulted to 5.28 for now, add 5.30 ports and fix problems in them as they're found, and once everything is building then switch the default to 5.30. This seems sensible to me.

Reply | Threaded
Open this post in threaded view
|

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

Jason Liu
In reply to this post by Daniel J. Luke
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 <[hidden email]> wrote:
On Jun 22, 2020, at 10:59 AM, Ken Cunningham <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

ryandesign2
Administrator
In reply to this post by Ken Cunningham


On Jun 22, 2020, at 09:59, Ken Cunningham wrote:

> Perhaps unavoidable in some cases, but if you look around the web, this is in fact the #1 complaint about MacPorts: bloat.

I can't corroborate that claim, but of course we are interested in reducing bloat in MacPorts and welcome any suggestions or improvements toward that end.

For example, if the complaint is that multiple versions of perl or python3 get pulled in during a build, we should fix that if we can by standardizing on a particular version and/or by offering variants so that the user can choose the one they want.

I admit I have been choosing not to add python3 variants in ports lately, choosing instead to standardize on python38 as the version to use (since that is the latest stable version and the one used by default in the python 1.0 portgroup); this is less work for maintainers since there are fewer opportunities for something to break. I hope that this choice is satisfactory.

Some perceived bloat is unavoidable if we want to continue to following our current practices. For example, if a port requires a perl module, then we use a MacPorts perl and module port. Installing another copy of perl may be perceived by the user as bloat since there's a "perfectly good" version of perl already provided by macOS, but we don't want to pollute the user's system with perl modules installed outside of MacPorts, so we keep our own perl and its modules all self contained in our prefix. There's also the announcement from Apple that we've mentioned before that scripting languages will not be preinstalled on a future version of macOS, so it behooves us to prepare for the time when we will need to use our own perl, python and other scripting languages even if we don't need nonstandard modules.

Reply | Threaded
Open this post in threaded view
|

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

ryandesign2
Administrator
In reply to this post by Jason Liu


On Jun 22, 2020, at 22:26, Jason Liu wrote:

>> 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.

For perl, I can understand Daniel's point somewhat since perl is a very old language and not a lot changes from release to release. There is a high likelihood that a module compatible with one version of perl will be compatible with the next newer version, although perl5.26 was a notable recent exception.

But for python, I would strongly oppose this. It seems like a lot more things change in each new python release, with a likelihood that modules will be broken or need updates to be compatible. It's not feasible for any one maintainer to update a hypothetical python3 port to a new major version and verify that all py3-* modules are compatible with it. And without such verification, just blindly committing an update, it falls to users to experience the breakage and report it to us. This degrades the user experience.

Our current strategy ensures things continue to work for users. If we add python38, that doesn't impact users using python37. If the user uses a module that's not yet compatible with python38, that's fine; they can stay on python37 until that gets fixed. Each module can be fixed at its own pace.

My thoughts for php are the same as those for python.


> Or, going with Ken's method and "setting" the default python version that all ports will use.

If you mean that users should have a way to set such a default python version, that's what variants are for. We have standardized the variant names that ports should use for providing functionality for a python version (e.g. the +python38 variant for python 3.8 support). This way, users can put +python38 into their variants.conf if they want that variant to be chosen for any ports that offer it. If we want to enhance the user experience of this functionality, we would need to add python variants to the ports that currently specify only a single version. This is extra and sometimes nontrivial work for the maintainer to do initially to set those variants up, and it's more work going forward as the maintainer needs to test each update of the port with each version of python (or likely forget to do so, eventually resulting in a problem for users who aren't using the default, which they then have to report to us, which is a bad user experience).

It's also more work for the user if the default variant changes and they want to switch to the new default. That's https://trac.macports.org/ticket/46956

If you mean that MacPorts management should state that a particular version of python shall be used by all ports, I think we've already stated that it shall be python38 or whatever is specified as the default in the python 1.0 portgroup (and that should be the latest stable version of python, although it is acceptable if it is not updated immediately after the release of a new version of python to accommodate testing and resolving some initial issues with the new version). The problem is there is no enforcement mechanism and it is up to each portfile maintainer to ensure that their ports do this. There is no good way to just magically make all ports that use python use a different version. Each port needs to be modified by hand and tested to ensure it still works with that change.

MacPorts is a volunteer project. There are a zillion opportunities for people to contribute. One way is to identify ports that depend on older python versions, update them to use newer versions and verify they still work, and submit a PR.

If you mean that MacPorts base or an include file in the ports tree should define a variable for the currently accepted perl or python version and ports should use this variable in declaring their dependencies and so forth, that's been suggested before but is not possible with how MacPorts base currently works with regard to the portindex. See https://trac.macports.org/ticket/59839


> 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.

Nothing should be arbitrary. If only a single version of python is chosen for a port, it should be the one that's set as the default in the python 1.0 portgroup.



Reply | Threaded
Open this post in threaded view
|

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

Jason Liu
In reply to this post by ryandesign2
Would it be possible to sort of split the difference? i.e. not _just_ have one single perl5 port and get rid of all the individual point releases, but rather to add perl5 as a sort of "metapackage" that is essentially the same as perl5.30. I guess metapackage isn't the right word, either. In reality more like, it's the same package as perl5.30, but simply with a more generic name that maps to whatever specific release has been blessed as the MacPorts default perl. So, these ports would all exist:

  • perl5 <= the "metapackage", and is actually the same port as perl5.30, perl5.32, or whatever is deemed to be the current MacPorts default perl.
  • perl5.30
  • perl5.28
  • perl5.26
  • ...
So if a particular port is okay with blindly using a version of perl that tracks with the latest MacPorts default perl, they can use perl5. If a port breaks when the MacPorts default perl gets changed, then the port could still revert back to specifying a specific version of perl, by simply changing the perl5 to perl5.28.

-- 
Jason Liu


On Mon, Jun 22, 2020 at 11:21 PM Ryan Schmidt <[hidden email]> wrote:
I've just realized this discussion has been to the old list address from macosforge. Please always use the new list addresses at lists.macports.org.


On Jun 22, 2020, at 14:34, Daniel J. Luke wrote:

> We should just have one perl5 port that tracks the current release.

You say this every year (or at least often).

Are you volunteering to be the one to ensure that every port that uses perl is compatible with the new perl release when it comes out? Without someone to do that, blindly upgrading everything from say perl 5.28 to 5.30 will likely break ports.

Do you remember perl 5.26? It broke a lot of ports, requiring a lot of fixes like this to be added: https://github.com/macports/macports-ports/commit/454eb2b0608266ab7bdf51a82d690be0f97610fe

The strategy currently being employed by those volunteers who are maintaining the perl ports is to keep everything defaulted to 5.28 for now, add 5.30 ports and fix problems in them as they're found, and once everything is building then switch the default to 5.30. This seems sensible to me.

Reply | Threaded
Open this post in threaded view
|

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

ryandesign2
Administrator


On Jun 22, 2020, at 23:00, Jason Liu wrote:

> On Mon, Jun 22, 2020 at 11:21 PM Ryan Schmidt wrote:
>
>> I've just realized this discussion has been to the old list address from macosforge. Please always use the new list addresses at lists.macports.org.
>>
>>
>> On Jun 22, 2020, at 14:34, Daniel J. Luke wrote:
>>
>> > We should just have one perl5 port that tracks the current release.
>>
>> You say this every year (or at least often).
>>
>> Are you volunteering to be the one to ensure that every port that uses perl is compatible with the new perl release when it comes out? Without someone to do that, blindly upgrading everything from say perl 5.28 to 5.30 will likely break ports.
>>
>> Do you remember perl 5.26? It broke a lot of ports, requiring a lot of fixes like this to be added: https://github.com/macports/macports-ports/commit/454eb2b0608266ab7bdf51a82d690be0f97610fe
>>
>> The strategy currently being employed by those volunteers who are maintaining the perl ports is to keep everything defaulted to 5.28 for now, add 5.30 ports and fix problems in them as they're found, and once everything is building then switch the default to 5.30. This seems sensible to me.
>
> Would it be possible to sort of split the difference? i.e. not _just_ have one single perl5 port and get rid of all the individual point releases, but rather to add perl5 as a sort of "metapackage" that is essentially the same as perl5.30. I guess metapackage isn't the right word, either. In reality more like, it's the same package as perl5.30, but simply with a more generic name that maps to whatever specific release has been blessed as the MacPorts default perl. So, these ports would all exist:
>
> • perl5 <= the "metapackage", and is actually the same port as perl5.30, perl5.32, or whatever is deemed to be the current MacPorts default perl.
> • perl5.30
> • perl5.28
> • perl5.26
> • ...
> So if a particular port is okay with blindly using a version of perl that tracks with the latest MacPorts default perl, they can use perl5. If a port breaks when the MacPorts default perl gets changed, then the port could still revert back to specifying a specific version of perl, by simply changing the perl5 to perl5.28.

"If a port breaks" goes back to what I said above: either you're spending days testing every module before a major perl update to determine which ones break, or you're planning to rely on users noticing and reporting the breakage. I don't want our users to experience breakage and have to report it, because it is likely that some portion of those users will not report the breakage and will instead equate the broken port with MacPorts itself being broken and abandon MacPorts. I don't want to give users reasons to abandon MacPorts.

I don't think adding a set of ports for "the current version of perl" solves the maintenance problem of having multiple versions of perl.



Reply | Threaded
Open this post in threaded view
|

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

Nils Breunese
In reply to this post by Jason Liu
Jason Liu <[hidden email]> wrote:

Would it be possible to sort of split the difference? i.e. not _just_ have one single perl5 port and get rid of all the individual point releases, but rather to add perl5 as a sort of "metapackage" that is essentially the same as perl5.30. I guess metapackage isn't the right word, either. In reality more like, it's the same package as perl5.30, but simply with a more generic name that maps to whatever specific release has been blessed as the MacPorts default perl. So, these ports would all exist:

  • perl5 <= the "metapackage", and is actually the same port as perl5.30, perl5.32, or whatever is deemed to be the current MacPorts default perl.
  • perl5.30
  • perl5.28
  • perl5.26
  • ...
So if a particular port is okay with blindly using a version of perl that tracks with the latest MacPorts default perl, they can use perl5. If a port breaks when the MacPorts default perl gets changed, then the port could still revert back to specifying a specific version of perl, by simply changing the perl5 to perl5.28.

There already is a perl5 wrapper port: https://ports.macports.org/port/perl5/summary

Its version is currently 5.26.1 and it has perl5_26, perl5_28 and perl5_30 variants.

Nils.
Reply | Threaded
Open this post in threaded view
|

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

ryandesign2
Administrator


On Jun 22, 2020, at 23:21, Nils Breunese wrote:

> Jason Liu wrote:
>
>> Would it be possible to sort of split the difference? i.e. not _just_ have one single perl5 port and get rid of all the individual point releases, but rather to add perl5 as a sort of "metapackage" that is essentially the same as perl5.30. I guess metapackage isn't the right word, either. In reality more like, it's the same package as perl5.30, but simply with a more generic name that maps to whatever specific release has been blessed as the MacPorts default perl. So, these ports would all exist:
>>
>> • perl5 <= the "metapackage", and is actually the same port as perl5.30, perl5.32, or whatever is deemed to be the current MacPorts default perl.
>> • perl5.30
>> • perl5.28
>> • perl5.26
>> • ...
>> So if a particular port is okay with blindly using a version of perl that tracks with the latest MacPorts default perl, they can use perl5. If a port breaks when the MacPorts default perl gets changed, then the port could still revert back to specifying a specific version of perl, by simply changing the perl5 to perl5.28.
>
> There already is a perl5 wrapper port: https://ports.macports.org/port/perl5/summary
>
> Its version is currently 5.26.1 and it has perl5_26, perl5_28 and perl5_30 variants.

Yes, but that's for users to use. It's not for ports to declare a dependency on, unless they don't need any perl modules.

The perl5 port is also unique and not a pattern we want other ports to follow. Other ports (python, php, etc.) instead use the "select" mechanism, which again is for a user's convenience and is not for other ports to rely upon.

Reply | Threaded
Open this post in threaded view
|

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

Mojca Miklavec-2
In reply to this post by Daniel J. Luke
On Mon, 22 Jun 2020 at 21:34, Daniel J. Luke wrote:
>
> 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)

I would say that we happily accept a pull request that "just bumps"
all dependents of perl5[.x].
Then all the ports will magically work with 5.30.

I seriously mean that. In the past I've done some batch updates, but
it's still hundreds of ports, and it's a non-trivial amount of work
even if the individual updates are trivial. At least in the ports I
touched I tried to ensure that the perl version is only mentioned once
and the variable is being reused elsewhere, so you just need to
replace 5.28 with 5.30, revbump and see if the ports stil builds (in
most cases it does; there are some clusters of software that need to
use the exact same version of perl at once).

> OR some enhancement to base to make it so the revbump is unnecessary.

That's not feasible. Unless the enhancement is to uninstall all ports
and reinstall them from scratch.

Mojca
Reply | Threaded
Open this post in threaded view
|

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

Ken Cunningham
In reply to this post by ryandesign2


On Jun 22, 2020, at 8:32 PM, Ryan Schmidt <[hidden email]> wrote:

I can't corroborate that claim, but of course we are interested in reducing bloat in MacPorts and welcome any suggestions or improvements toward that end.


I’m surprised — that has always been near point #1 on every homebrew vs. macports discussion, and (was for years) put forth as the major justification for homebrew over macports. Eg just one top-of-the-list hit from google: <https://www.slant.co/versus/1588/1674/~macports_vs_homebrew>

PRO
 Homebrew tries very hard to use existing tools and libraries

Homebrew’s recipes try very hard to use the existing tools and libraries in OS/X, so they tend to build much faster and require fewer dependent libraries.

PRO
 Builds quickly and requires few dependencies

Homebrew as much as possible uses already existing libraries and tools to install software thus making builds quick and requiring few dependencies.




multiple versions of perl or python3 get pulled in during a build, we should fix that if we can by standardizing on a particular version

Yes, that indeed is my point. 

curl, for example, now has a choking amount of dependencies, including 2 perl versions and a python (or two), and yet actually builds on current macOS systems without even a single added dependency just by downloading the source and building it.

Feel free to set the bar, if you care to. And hopefully, don’t move it too often…IMHO.

K
Reply | Threaded
Open this post in threaded view
|

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

ryandesign2
Administrator


On Jun 23, 2020, at 00:57, Ken Cunningham wrote:

> On Jun 22, 2020, at 8:32 PM, Ryan Schmidt wrote:
>
>> I can't corroborate that claim, but of course we are interested in reducing bloat in MacPorts and welcome any suggestions or improvements toward that end.
>
> I’m surprised — that has always been near point #1 on every homebrew vs. macports discussion, and (was for years) put forth as the major justification for homebrew over macports.

I can't corroborate your claim because I have never attempted to gather authoritative statistics about why people choose MacPorts or Homebrew.

One of the MacPorts advantages you've often touted is how well it works on older systems, something Homebrew doesn't even attempt to do. And I know you're one of the driving forces behind that, and I'm very grateful for that. So you can surely appreciate that one of the ways MacPorts is able to do this is by using its own software instead of that provided by the system. I've often run into the problem that a build will fail on Snow Leopard because its version of Python is too old, so then we have to add a dependency on MacPorts python. To a user of a newer system, that might be perceived as bloat. We could code the port more carefully, only using MacPorts python if it is known that macOS python is too old, and I've done that in some ports, but sometimes we don't know exactly where the cutoff is and so we do what we can at that moment and commit a fix to just make it work. You yourself have suggested multiple times that we should move more towards always using MacPorts compilers on older systems even for ports that don't require it because it's less easier for the maintainer to be able to assume a certain recent baseline functionality, and I've argued against that (on the basis of bloat, on the basis of extra build time on the buildbot as dependencies get activated and deactivated, on the basis of extra wear and tear on the SSDs used on the buildbot).


>
>>
>> multiple versions of perl or python3 get pulled in during a build, we should fix that if we can by standardizing on a particular version
>
> Yes, that indeed is my point.
>
> curl, for example, now has a choking amount of dependencies, including 2 perl versions and a python (or two), and yet actually builds on current macOS systems without even a single added dependency just by downloading the source and building it.

My ports are slightly out of date but I don't see a choking amount of dependencies for curl on High Sierra:

$ port rdeps curl
The following ports are dependencies of curl @7.70.0_0+ssl:
  xz
    lbzip2
    libiconv
      gperf
    gettext
      ncurses
  pkgconfig
  libidn2
    autoconf
    automake
    libtool
      xattr
        unzip
    libunistring
      perl5
        perl5.28
          db48
          gdbm
            readline
      texinfo
        help2man
          p5.28-locale-gettext
        perl5.30
  libpsl
    python38
      bzip2
      expat
      libedit
      libffi
      openssl
        zlib
      sqlite3
      python_select
      python3_select
    glib2
      libxml2
        icu
      pcre
  curl-ca-bundle


If you are on an older system you may have additional dependencies in the chain, likely compilers, but that's not curl's fault; it doesn't impose any compiler restrictions. Its dependencies might.

Note that the curl portfile makes no mention at all of python, so if there is an unnecessary python dependency in the chain you'll have to look somewhere other than curl.

Per my rdeps above, the only python used anywhere in the chain is python38, used as a build dependency by libpsl. libpsl used to depend on port:python27 but it was changed to python37 because python2 is eol:

https://trac.macports.org/ticket/58120

It was later updated to python38.

If the build still supports python2, it could be changed to use /usr/bin/python but then it's possible that again for example Snow Leopard's python would be too old. If the build requires python3, not all versions of macOS ship with python3.


The curl-ca-bundle subport does mention a build dependency on perl because the build system uses perl. It used to depend on a specific version of perl because it needed a specific perl module, but that was changed 12 years ago to require merely path:bin/perl:perl5.

https://github.com/macports/macports-ports/commit/6ef755830ba60f7b5977890d6cd46cea7dd0c8db

It is possible that this could be changed to bin:perl:perl5 to allow the macOS version of perl to be used. I haven't tried that but if we want to make that change then I would want to verify that it works as far back as Tiger.


curl and libpsl are both distributable and perl5 and python38 are only build dependencies so they shouldn't get installed on most users' systems just because of their use here, so I would not consider these to be contributors to bloat.


> Feel free to set the bar, if you care to. And hopefully, don’t move it too often…IMHO.

I'm not sure what you mean.

Reply | Threaded
Open this post in threaded view
|

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

Dr M J Carter-2
In reply to this post by Michael_google gmail_Gersten
On Mon, Jun 22, 2020 at 01:26:54PM -0700, Michael wrote:

>
> On 2020-06-22, at 1:12 PM, Dr M J Carter <[hidden email]> wrote:
>
> > Rats: you beat me to it.  I'll restrict myself to reminiscing about
> > dylibs having allegedly been invented (by Sun?) out of embarrassment,
> > on finding hello.c was bloated, to 3MBytes iirc, by printf() dragging
> > in half the known universe at link time.
>
> Oh, it's not all that bad. Just the standard io library, the file
> buffering library, the larger startup and exit code, math library
> (because some of the formatting options required something, probably
> rounding, I have long since forgotten), error text translation
> (gotta be able to report the error numbers as human readable text,
> after all), some string library routines -- oh, right, that's ALL of
> the string library, and ... did I leave anything out?

What was brought to my attention at the time was writing on an X
screen.  As X11 was a novelty at the time, I didn't know to ask
whether xterm or direct drawing was involved, or whether stdlib (or
whatever) was playing it both ways.  (If anyone needs to correct me on
this, I pre-emptively plead bitrot in the wetware.)

PS: Apologies for blindly replying-to-all for the wrong value of all.

--
Dr Martin J Carter
Sysadmin to the Stars, and Old Fart in Residence
Astrophysics, University of Oxford
Reply | Threaded
Open this post in threaded view
|

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

Ken Cunningham
In reply to this post by ryandesign2


On Jun 23, 2020, at 00:48, Ryan Schmidt <[hidden email]> wrote:

>> Feel free to set the bar, if you care to. And hopefully, don’t move it too often…IMHO.
>
> I'm not sure what you mean.

Exactly what I stated with...

If MP would pick one perl and one python that everyone is meant to use, declare it, and don't change it too often, that would be a Good Thing.

If that is actually what is being done in this thread (I think it is, but I can't tell for sure), to perl5.28 and python38, let's make that clear.

I'll go sort out what added perl5.30 to curl's build deps and revert it.

And everyone might stop randomly changing ports to use perl 5.30 or defaulting to some other python until some year in the moderately distant future.

Less work, less bloat, more happiness -- it's just a win all around.

And if that is impossible, unacceptable, or undesirable, then so be it. At least we tried...

K
Reply | Threaded
Open this post in threaded view
|

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

Ken Cunningham
In reply to this post by ryandesign2


> On Jun 23, 2020, at 00:48, Ryan Schmidt <[hidden email]> wrote:
>
> You yourself have suggested multiple times that we should move more towards always using MacPorts compilers on older systems even for ports that don't require it because it's less easier for the maintainer to be able to assume a certain recent baseline functionality, and I've argued against that (on the basis of bloat, on the basis of extra build time on the buildbot as dependencies get activated and deactivated, on the basis of extra wear and tear on the SSDs used on the buildbot).

I do think this would be a good idea. As soon as the default xcode compiler can't build most ports, make one macports-clang the default compiler for all older systems.

Right now, this might mean all systems up to 10.11 default to clang-9.0, for example. And don't change that too often either.

Tons of needless work would disappear.

Is it impossible to avoid the buildbot uninstall/reinstall issue? That would be an unfortunate reason not to do this.

K
12