[MacPorts] #73854: oracle-instantclient: automatic download of distfiles no longer possible ; outdated versions ; updated archs

[MacPorts]

#73854: oracle-instantclient: automatic download of distfiles no longer possible ;
outdated versions ; updated archs
----------------------------------------------+------------------------
  Reporter:  BjarneDMat                       |      Owner:  BjarneDMat
      Type:  defect                           |     Status:  assigned
  Priority:  Normal                           |  Milestone:
 Component:  ports                            |    Version:
Resolution:                                   |   Keywords:
      Port:  oracle-instantclient php-oracle  |
----------------------------------------------+------------------------

Comment (by ryandesign):

 I am not working on this, but just to answer a few questions that have
 piled up:

 Replying to [comment:2 jmroot]:
 > It is unfortunate that this causes builds to fail every time the php
 Portfile is updated. I wonder if it makes sense to move php*-oracle ports
 to a separate Portfile, or if there's some other way to avoid the repeated
 mirroring and build failures.

 Since we don't have a distfiles-private server or mirroring mechanism set
 up, I avoided build failures before by manually downloading the oracle-
 instantclient files on my machine, manually copying them to each buildbot
 worker's distfiles directory, setting their modification date in the
 future so they wouldn't be auto-deleted, then scheduling the oracle-
 instantclient builds. This would produce binaries on the packages-private
 server that the buildbot could use to subsequently build the php*-oracle
 subports.

 I've taken care to do this for each new Intel buildbot worker as I set it
 up. There are binaries of oracle-instantclient on packages-private for all
 Intel macOS versions ([ticket:73230 except Tahoe] and Leopard) so there
 should be no build failures of php*-oracle on Intel buildbot machines that
 are caused by missing oracle-instantclient. This is confirmed by the
 [https://ports.macports.org/port/php83-oracle/details/ port health
 indicators].

 If there are failures of php*-oracle on Intel CI machines, that would
 happen if CI did not have access to the packages-private server, which has
 indeed been mostly or possibly completely broken for months because I
 haven't updated the list of allowed CI IP addresses on the packages-
 private server. The long-term plan is to move packages-private to our new
 carola server and to allow access by VPN rather than by IP whitelisting.

 On arm64, the oracle-instantclient port doesn't currently support arm64 so
 there is a build failure when php*-oracle can't install that dependency
 for arm64. The workaround for that would be to indicate the same
 `supported_archs` in the php*-oracle ports as is set in oracle-
 instantclient. This seems to be a general MacPorts limitation at this
 time: If a port restricts its `supported_archs`, all ports depending on it
 must be marked at least as restrictively.

 Replying to [comment:3 BjarneDMat]:
 > There'll be a separate `php-oracle` port in the near future - `php-
 oracle` has been evicted from `php` >= 8.4 . It had just simply eluded my
 attention, that that was the case - My Bad !
 > According to https://pecl.php.net/package/PDO_OCI it ought to be
 possible to remove `php-oracle` entirely from `lang/php/Portfile` if it's
 the consensus, that that's the desired way to go.

 Looks like for php < 8.3 the new php-oracle port would have to use version
 1.0 from 2005, and for php ≥ 8.3 it can use the latest version. To
 decrease the version like this, the `epoch` in the new php-oracle port
 will need to be increased to `3` to be greater than its current value of
 `2` from the php portfile.

 Before moving this module to a new php-oracle port, compare the source
 code of the module from the 1.0 distribution with the ones included in the
 latest php source distriburtion to make sure there aren't any post-1.0
 improvements in the php source distribution that we would be reverting by
 going back to the 1.0 version.

 Instead of having the new php-oracle use 1.0 for php < 8.3, it could have
 separate cases for each version and continue to use the php source
 distribution for those older php versions.

 Replying to [comment:9 BjarneDMat]:
 > So ...
 > 1. it's missing the start `cd`
 > 2. the `dmg` isn't in the correct place after `hdiutil attach`

 My advice to use `use_dmg yes` assumed the port was using a standard
 extract phase. I did not remember that this port overrides the extract
 phase, and since the port did not use dmg distfiles I did not write that
 override to accommodate them; `use_dmg yes` evidently messes it up. I
 haven't gone back to try to re-learn why I did that but I'm sure I had a
 good reason at the time. If the reason no longer applies, you can remove
 the extract phase override. Otherwise, you would enhance the extract phase
 override to handle dmg files.

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