[MacPorts] #69154: Make a separate tree for 10.6 pre-release-specific fixes

MacPorts noreply at macports.org
Mon Jan 22 02:44:35 UTC 2024


#69154: Make a separate tree for 10.6 pre-release-specific fixes
----------------------------------+--------------------
 Reporter:  barracuda156          |      Owner:  (none)
     Type:  defect                |     Status:  new
 Priority:  Normal                |  Milestone:
Component:  ports                 |    Version:  2.8.1
 Keywords:  snowleopard, powerpc  |       Port:
----------------------------------+--------------------
 To begin with, for the context: there are very few ports which require
 fixes ''specific'' to the developer pre-release versions of 10.6 (relevant
 for PowerPC, but in fact as much applicable to Intel). Perhaps, something
 around 15–20 altogether, excluding versions of the same (there are several
 gccs which need identical fix, etc.). Which make up to about ~30 ports.

 However:

 1. Some of those'' in present form'' are not portable – in a sense they
 will compromise standard 10.6.x, at least potentially. So they should not
 be in the master in any case.
 2. As we know, there are maintainers who happen to oppose fixing their
 ports for pre-released macOS versions, which makes it impossible to fix
 those ports, regardless of whether fixes in question are generally
 desirable, sound etc.

 While I oppose the idea to move all PowerPC support to a separate tree or
 repo, I am perfectly fine, ''and in fact for,'' upon reconsideration,
 having a separate tree for 10a190, where I can place fixes which are
 genuinely required only for pre-release 10.6 and no other systems.

 This would solve, at least partly, a number of problems:

 0. We can have Pythons and GCCs fixed for 10a190 straightaway – I have
 those fixed and working, but Pythons fixes are blocked by their maintainer
 and GCC fixes in existing form are incompatible with regular 10.6 (and
 while I can make them compatible even now, I do not yet have a way to make
 in neatly).
 1. For developers and end-users there will be still an official trust-
 worthy source, even though a secondary one, which is preferable as
 compared to my personal repo.
 2. It will make situation transparent and easy to monitor for everyone who
 may wish: I do not want to keep being accused of introducing hundreds of
 10.6 ppc-specific hacks :) I admit a few hacks ''are'' in fact needed, and
 IMO they should be available to those in need of them, but Ken is right in
 that such fixes should not compromise any other systems; it is also
 understandable that in some cases portfiles are too complex already, and
 any extra code will make them less readable.
 3. I can also use such tree for experimental ports specifically targeting
 PowerPC (not specific to 10.6 ppc), but not being ready for the master.
 For example, SDL2 and VLC2. This gonna make it easier for others to test
 such ports (and maybe help with fixing them).
 4. If there is a separate tree to which I have commit rights, it make my
 life easier, after all. I will still have an incentive to make any fixes
 to that tree sane, concise and complying to Macports policies, since I
 hope that minimal and safe ones can be accepted into master, at least some
 of those. But a separate tree will make it easy to review for others, and
 I do not need to fight over each PR. At the same time it is perfectly safe
 (since all 10A190-specific stuff is not in the master and does not affect
 anyone at all) and also, hopefully, addresses Ken’s point of supposed
 difficulty of getting rid of my fixes (in a case Macports developers
 collectively decide in favor of that): removing a tree is trivial, if
 desired.

 It is not necessary, at least not from the start, to make any change to
 the base to pick such a repo in case one is on 10.6 ppc. It can be
 introduced as an isolated thing: though on Macports Github as a branch,
 nothing will address it, and if anyone wishes to use it, they will need to
 tweak their set-up manually.

 P. S. Addressing Kirill’s consideration re maintenance difficulty: if the
 tree is for 10A190 only, this is easy for me to maintain and rebase
 against the master regularly. I do it anyway for myself. In fact, it is
 mostly “do it once for a few ports and then just routinely rebase”.

 What do you all think?

-- 
Ticket URL: <https://trac.macports.org/ticket/69154>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list