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