[MacPorts] #60509: Upgrading ports sometimes breaks internet connection

[MacPorts]

#60509: Upgrading ports sometimes breaks internet connection
---------------------+--------------------
  Reporter:  iEFdev  |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  base    |    Version:  2.6.2
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by iEFdev):

 Thanks for all answers Ryan. 👍


 Replying to [comment:6 ryandesign]:
 > Replying to [comment:3 iEFdev]:
 > > ''32/64… MacPorts sometimes says I'm i386, but `uname` says x86_64.''
 >
 > There is an unfortunate terminology clash with the term "arch" in
 MacPorts.
 >
 > # ...
 >
 > Since you are on Lion, we know you have a 64-bit Intel processor; Lion
 and later require that. So I recognize that your situation is not
 identical to the one I mentioned on our 32-bit Snow Leopard build machine.
 But it had similarities that made me want to mention it anyway.

 Lion's a bit of a mess about the archtecture and how it's reported back.
 It actually shows different types with different commands, but also within
 `uname`:

 {{{
 $ uname -m
 x86_64
 $ uname -p
 x86_64
 $ uname -v
 ...; root:xnu-1699.32.7~1/RELEASE_X86_64
 $ uname -pv
 ...; root:xnu-1699.32.7~1/RELEASE_X86_64 i386
 $ uname -a
 ...; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
 }}}

 ''I found that a bit funny. :)''

 …plus `arch` says i386, and `machine` says i486.

 They have diff meaning and usage, but still…

 I ''think'' I've read somewhere that Lion has some sort of mixed version,
 and that 10.8 was the first ''true'' 64-bit.


 [[br]]

 > Replying to [comment:5 iEFdev]:
 > > One ''could'' do the same line with `awk` instead – just to see if
 there's a difference? …if `grep|cut` is the problem.
 >
 > I don't think `grep` or `cut` specifically are the problem. I think part
 of the problem is we are spawning too many processes regardless what those
 processes are. Therefore one of my suggestions is to remove the use of all
 but the `ping` process and do the text processing in Tcl.
 >
 > # ...
 >
 > So far I see no evidence that this is a slow network problem. It seems
 more likely to me that MacPorts is overtaxing the OS by launching so many
 simultaneous processes and thereby using up so many file descriptors
 simultaneously.

 Yes, and that was part of the idea by using `awk`. The number of processes
 would be cut by a 3'rd. I saw the changeset now, and that will basically
 do the same thing… ''(ie. `ping` + all in one take)''. That change alone
 will probably solve the problem, but to cut down the number of mirrors as
 well sounds great.


 [[br]]

 > If you are suggesting that we should use a geoip database to determine
 the approximate location of the user and create a central database with
 geoip-derived locations of all of our hosts and use that data to choose a
 server close to the user, then those would be major changes to how
 MacPorts and its infrastructure works and it could certainly be discussed
 elsewhere (bring it up on the macports-dev mailing list if you are
 strongly interested in this) but it would be a lot of work and I'm not
 sure the end result would be so much more accurate than our current ping
 time check that it would be worth the effort.

 Well, that would be a giant implementation just for this - so, unless
 there are some real benefits for other parts as well, it sounds a bit too
 much. I see your point.

-- 
Ticket URL: <https://trac.macports.org/ticket/60509#comment:10>
MacPorts <https://www.macports.org/>
Ports system for macOS