Support for ancient machines and operating systems

Perry E. Metzger perry at piermont.com
Mon Jan 8 15:18:13 UTC 2024


On 1/8/24 10:12, Kirill A. Korinsky wrote:
>> I don't think there should be overly much in the way of trouble if 
>> legacy reasonably disciplined about frequently applying commits from 
>> upstream to legacy. If it's done often, then one doesn't risk falling 
>> far behind and having a giant mess to clean up. Someone would 
>> probably want to write something to semi-automate it based on a CI 
>> for legacy systems. Such work would be beyond the scope of the main 
>> project of course, but it would also make life easier for the people 
>> interested in legacy. It might even be possible to create some 
>> override mechanisms to parse in / "#include" a "legacy" portfile in 
>> with the upstream maintained portfile to reduce file diffs in legacy.
> Keep in mind that some new commits often broke old OS as well.
>
> For example upgrade Rust which can be seen like a disaster for old systems.

So I think that the solution there is (again) that legacy is disciplined 
about not pulling in stuff that breaks it. David Gilman is right that a 
social problem isn't always best solved with technology, but I think in 
the present case, we have a great deal of flexibility thanks to technology.

The Portfile format is, ingeniously, a tcl script. By adding a small 
amount of fixes like allowing overlaying the main Portfile with a legacy 
Portfile etc., it may be possible to make the whole thing work quite 
cleanly without bothering "upstream" overly much.

It's unclear to me whether a repository consisting of "overlays" or a 
fork that pulls from upstream is the better mechanism, but that's a 
technical detail that can be hashed out.

Perry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20240108/84a531ed/attachment-0001.htm>


More information about the macports-dev mailing list